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Legyen On is 
a NAGYOK között! 


slisrnert Microsoft . linősítésel val melyiké tét EL 
Uj konstrukciók, új képzések, kedvezőbb árak! 


Válassza ki az Önnek megfelelő 
minősítést és képzési konstrukciót! 


Microsoft rendszeradminisztrátor (MCSA) képzés 80 óra 
már nettó 249.000 Ft / főtől 
A kisebb informatikai rendszereket és hálózatokat üzemeltető szakemberek szá- 
mára ajánljuk, akiknek feladatuk lesz Windows 2003 alapú hálózatok telepítése, 
konfigurálása, adminisztrálása, karbantartása. 
Windows XP tréning Kit-tel Következő kezdési időpont: szeptember 27. 
Microsoft rendszermérnök (MCSE) képzés 160 óra 
már nettó 499.000 Ft / főtől 
Nagy, összetett informatikai rendszereket és hálózatokat üzemeltető szakemberek 
képzése, akiknek feladatuk lesz Windows 2003 alapú hálózatok teljes körű admi- 
nisztrálása, támogatása, tervezése. 
Windows XP tréning Kit-tel Következő kezdési időpont: szeptember 27. 
Microsoft adatbázis-adminisztrátor (MCDBA) képzés 156 óra 
már nettó 459.000 Ft / főtől 
Microsoft SOL Server 2000/2005 alapú adatbázisrendszerek teljes körű üzemel- 
tetésével, támogatásával, karbantartásával, tervezésével és implementálásával 
megbízott szakemberek részére ajánlott képzés. 

Következő kezdési időpont: szeptember 27. 
Microsoft .NET alkalmazásfejlesztő képzés 184 óra 
már nettó 519.000 Ft / főtől 
Kezdő fejlesztők, programozók számára ajánlott képzés, akiknek feladatuk 
lesz Windows és webes alkalmazások készítése, szolgáltatások fejlesztése 
Visual Studio .NET segítségével. 

Következő kezdési időpont: szeptember 27. 


Rugalmas időbeosztás, különböző tanfolyamokat és segédanyagokat, 
vizsgakedvezményeket tartalmazó oktatási csomagok, 
további (15.000-25.000 Ft értékű) oktatási kedvezmények. 


A tanfolyamokkal és akciókkal kapcsolatos további tudnivalók weboldalunkon 
találhatók, vagy kérjük, keresse szervezőnket! 
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III ézzünk egy kicsit a jövőbe. A 
i Microsoft közzétette a Win- 
ü I dows Server termékcsalád- 
dal kapcsolatos fejlesztéseit, tervezett 
termékbejelentéseit. Összegezzük, mi- 
kor milyen újdonságra számíthatunk. 
A Windows Server 2003 SP1 megjele- 
nése 2004 év végére várható. Az SP1 
a legújabb biztonsági frissítéseket, ja- 
vításokat fogja tartalmazni, és olyan 
szolgáltatásokat foglal magában, me- 
lyekkel növelhető a rendszerek bizton- 
sága (ezek megtalálhatók a Windows 
XP SP2-ben is), továbbá egy , Security 
Configuration Wizard" varázslót is tar- 
talmaz majd. Az SP1 telepítésekor a 
tűzfal már alapbeállításként is be lesz 
kapcsolva. A Windows Server 2003 
SP1 még nagyobb teljesítményt és 
rendelkezésre állási időt is garantál. 
A Windows Server 2003, 64-bit for 
Extended Systems az SP1 csomaggal 
egy időben jelenik meg, 2004 végén. 
Ez a teljesen különálló operációs rend- 
szer, a jelenlegi Windows Server 2003 
64-bit Edition követő terméke lesz, 
mely már az olyan újonnan bejelentett 
64-bites technológiákat is támogatja, 
mint például az AMD Opteron vagy In- 
tel Xeon64 processzorok. 
2005 második felében jelenik meg a 
Windows Server 2003 Release2, mely 
a jelenlegi Windows Server 2003-at hi- 
vatott felváltani. A tavaly áprilisban be- 
mutatott Windows Server 2003 verzió 
megjelenése óta megjelent vagy 
kiegészített szolgáltatásokon (például 


Windows SharePoint Services, Rights 
Managment Services, — Automated 
Deployment Services, Services For 
Unix 3.5) túl további új szolgáltatáso- 
kat, fejlesztéseket tartalmaz majd a 
Windows Server 2003 R2. A Microsoft 
véleménye szerint ugyanis egy új, fris- 
sített termék sokkal könnyebben hasz- 
nálható, mintha külön kellene ezeket a 
frissítéseket és értéknövelő szolgálta- 
tásokat telepíteni a rendszerre. Az R2 
komponensei már tartalmazzák a Win- 
dows Server 2003 SP1-et, és hangsú- 
lyos a biztonságos és folyamatos 
munkahelytől távoli munka támogatá- 
sa is. Az R2 továbbfejlesztett és haté- 
konyabb kiszolgáló beüzemelést és 
felügyeletet tesz lehetővé. Egyébként 
ugyanazon feltételekkel lehet majd 
hozzájutni, mint a Windows Server 
2003-hoz. A frissítési garanciával ren- 
delkező ügyfelek (SA/EA) természete- 
sen ingyenesen kapják meg. 

A Windows Server ,Longhorn" válto- 
zat várhatóan 2007-ben jelenik meg. A 
termék új generációs webalkalmazás 
platformot, központosított és egysze- 
rűbb alkalmazásplatform menedzs- 
mentet, valamint teljesen, alapjaitól új- 
ratervezett rendszermenedzsmentet, 
gyorsabb és automatikusabb rend- 
szerfelügyeletet tesz lehetővé. A rend- 
szer az újabb hardvereket és szabvá- 
nyokat is támogatja maja, illetve to- 
vábbfejlesztik a közismert alapszol- 
gáltatásokat is. A termék első béta vál- 
tozata a jövő évben várható. 
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Automatikus mermrmória- 
gazdálkodás a .NET-ben 2. rész 


FINALIZÁCIÓ ÉS TELJESÍTMÉNYOPTÍMALIZÁLÁS 

Folytatjuk a GC működésének felderítését. Megismerkedünk 

az , újraéleszthető" objektumokkal, a gyenge referenciákkal, az objektum- 

generációkkal és a GC valós idejű monitorozására szolgáló eszközökkel. 
egismertetjük továbbá az erőforrások felszabadítását végző 

Dispose és Close metódusok helyes megvalósításának módját is. 





ASPRP.NET 2.Of(VvVhidbey) 


Mi VÁRHATÓ A 2005-ÖS ASP.NET-BEN? 1. RÉSZ 
ADATELÉRÉS, ADATFORRÁS-VEZÉRLŐK, GRiIDVIEW 





Cikksorozatot indítunk a . NET Framework következő 
generációjáról, amelynek Whidbey a kódneve. Az első három 
részben az ASP.NET-ről lesz szó, aztán az ADO.NET-ről, 
majd a . NET Framework egyéb újdonságairól. 








vVVindows szolgáltatások 3. rész 
NT AUTHORITYNWNNETWORKSERVICE 


A sorozat előző részében a L ocalService fiók nevében 
futó szolgáltatásokat pécéztük ki, most a másik, 

a LocalSystem fiók használatának mértékéhez 
képest törpe minoritásnak számító NetworkService 
fiókhoz köthető szervizek kerülnek a fókuszba. 


Két üzleti platform 

rövid kiértékelése 

A LiNUX És A WINDOWS ÖSSZEHASONLÍTÁSA 

Sok vállalat van, amely a nagyszámítógépekről és a UNIX alapú 
rendszerekről az Új Intel alapú megoldásokra való átállást 


fontolgatja, hiszen azok az előbbiek költségeinek törtrészéért 
nyújtanak ugyanolyan, sőt akár nagyobb teljesítményt. 


Módszertanok, MűdezőPtArak, 
módszertanok 


A szoftverfejlesztési projektek olyan speciális 
tulajdonságokkal rendelkeznek, amelyek miatt 

sajátos szakmai és menedzsmentmódszerekre van 
szükségünk. Ezeket járjuk körül ebben a cikkben, 
különböző gyakorlati szempontok figyelembevételével. 








Uzletiintelligencia-szoftverek 
MS SOL 2000 REPORTING SERVICES III. RÉsZ 


Az üzleti intelligencia minden vállalat életében nélkülözhetetlen, 
segítségével megalapozott döntéseket hozhatunk, amelyek sikeressé 
tesznek minket a piacon. Az üzleti intelligencia nem feltétlenül igényel 

egy teljes OLAP-ot vagy adatbányászatot, mint amilyenek az SOL Server 
Analysis Services-re épülő megoldások, de minden üzletiintelligencia- 
megoldásnak van egy közös eleme: a Jelentések (Report-ok). 





Ami a hivatalos Microsoft 
tanfolyamokból kimaradt... 


EXCHANGE 2000/ EXCHANGE SERVER 2008 III. RÉSZ 


szenyune 








Exchange témában egyelőre ez az utolsó cikk ebben 
a sorozatban. További apróságok mellett 

egy új kiegészítő komponenst és ennek 

a ,kiegészítésnek a kiegészítését" ismertetjük. 









































Microsoft ERMI v 1.2 — 1.rész 


A MICROSOFT ELSŐ ASP.NET ALAPÚ ÜZLETI ALKALMAZÁSA 


szeptemberben jelenik meg Magyarországon a Microsoft 
ügyfélkapcsolat-kezelési rendszere, a Microsoft Customer 
Relationship Management (CRM) 1.2 lokalizált változata. 
Cikksorozatunk első része rövid áttekintést nyújt a rendszer 
szolgáltatásairól és az alkalmazott technológiákról. L eírásunk 
természetesen nem teljeskörű, néhány példán keresztül 
mutatjuk be az általunk leginkább érdekesnek ítélt funkciókat. 


Dr VVatson 


BOLONDBIZTOS EFS 








Ebben a cikkben nem az EFHS 
(Enerypting File System) működéséről, 
vagy használatáról olvashatnak, 
hanem arról, hogyan tehető 

az EFS-rendszer bolondbiztossá, 
hogyan növelhető a megbízhatósága 

a titkosított fájlok kibontásához 
szükséges magánkulcsok központi 
mentésével. Kiválasztott vállalatunknál 
vVindows Server 2003-as 
tartománykörnyezetet feltételezünk, 
amelyben egy Enterprise 

(azaz Active Directoryval integrált) 

CA Server is van. 


as TE GHNOLHM Si A 03. BE KART ES DNS az OG a a 65 















































Automatikus 
mermóriagazdálkodás 


a .(NET-ben 


FINALIZÁCIÓ ÉS TELJESÍTMÉNYOPTÍMALIZÁLÁS 


Folytatjuk a GC működésének felderítését. Megisrnerke- 


dünk az , újraéleszthető" objektumokkal, a gyenge refe- 


renciákkal, az objektumgenerációkkal és a GC valós idejű 


monitorozására szolgáló eszközökkel. Megismertetjük 


továbbá az erőforrások felszabadítását végző Dispose 


és Close metódusok helyes megvalósításának módját is. 


A Finalize metódusok futtatásának 
részletei 

Az első részben leírtak alapján bárkiben joggal merülhet fel 
a gyanú, hogy valami nincs egészen rendben a Finalize 
metódusok meghívása körül. Azt mondtuk ugyanis, hogy a 
GC előbb memóriaszemétnek minősít egy objektumot (va- 
gyis megállapítja, hogy egyetlen referencia sem mutat rá), 
majd ezután meghívja a referencia nélküli objektum egyik 
metódusát. Hogyan lehetséges ez? A történet már az ob- 
jektum létrehozásakor kezdődik. Új objektum létrehozása- 
kor, ha annak osztályában van Finalize metódus, az objek- 
tum referenciája bekerül a GC által erre a célra fenntartott 
sorba (Finalization gueue). A sor elemei tehát azokra az ob- 
jektumokra mutatnak, amelyek Finalize metódusát meg- 
szüntetésük előtt meg kell hívni. 

































































szabad 
terület 
Finalization 
10. objektum gueue 
1 9. objektum 9. ref 
[— 1 8. objektum ! 6. ref 
7. objektum 4. ref 
6. objektum 2. ref 
gyökér [ . ú. 
készlet 5. objektum 1. ref 
TT 4. objektum J-— 
7 Freachable 
3. objektum gueue 
2. objektum j-—— 
MT 1. objektum [—— 


























— A Finalization gueue 





Az ábrán látható 1., 2., 4., 6., 9. objektum tartalmaz Finalize 
metódust, tehát referenciáik felkerülnek a Finalization 
gueue-ba. Amikor a GC akcióba lép, a 2., 3., 6., 7. és 10. 
objektumra nem talál hivatkozást, tehát szemétnek minősíti 
azokat. Ezután végignézi a Finalization gueue-t, és ha talál 
az eltávolítandó objektumokra mutató hivatkozást, átmoz- 
gatja azokat a Freachable gueue-ba. A Freachable gueue 
szintén a GC által fenntartott adatstruktúra, amely a Finalize 
metódus futtatására előkészített objektumok. referenciáit 
tartalmazza. A begyűjtés után a heap az alábbi ábrán lát- 
ható képet mutatja: 













































































Finalization 
gueue 
szabad 9. ref 
terület 
4. ref 
MT] 9. objektum 
d 8. objektum 1. ref 
6. objektum 
GEkéi — HT 5 objektum vlene 
MT] 4.objektum [" 6. ref 
2. objektum [- 2. ref 
Mm] 1. objektum 























A heap az első begyűjtés után 


A 3. 7. és 10. objektum memóriaterülete felszabadult, mivel 
nem volt meghívandó Finalize metódusuk. A 2. és 6. objek- 
tum azonban továbbra is a memóriában maradt, referenci- 
ájuk pedig a Freachable gueue-ban tárolódik. 


ES 2004 03 


A Finalize metódusok meghívását önálló, erre a célra fenn- 
tartott programszál végzi, amely akkor aktivizálódik, ha a 
Freachable gueue-ban bejegyzések jelennek meg. A min- 
taprogramban [1] is ellenőrizhetjük ezt, ha A fő szál hash 
kódja menüponttal kapott értéket, és a Finalize metódusok- 
ban kiírt hash-értékeket összehasonlítjuk. Az értékek nem 
egyformák, tehát a Finalize metódusok külön szálon futnak. 
Az aktuális szál hash kódját a 


System. Threading . Thread . CurrentThread. 
4 GetHashCode() 


függvényhívás adja vissza. Érdekes jelenséget figyelhe- 
tünk meg, ha a mintaprogram WaitPendingFinalizers metó- 
dusából kivesszük a GC.WaitForPendingFinalizers(); sort. 


static void WaitPendingFinalizers() ( 
Console.WriteLine("A Finalize metódusok 
4 meghívása elindult."); 
//GC.WaitForPendingFinalizers(); 
Console.WriteLine("A Finalize metódusok 
$. Jefütottak."); 


A metódushívás funkciója az, hogy blokkolja az adott szál 
futását, amíg a Finalize metódusokat futtató programszál 
elvégzi feladatát. Ha így futtatjuk a Szemetelés, majd a 
Szemétgyűjtés menüpontokat, a képernyőre írt üzenetek 
helyes sorrendje teljesen felborul a párhuzamosan futó 
szálak miatt. A Finalize metódus lefutása után az adott ob- 
jektum referenciája törlődik a Freachable gueue-ból, így 
már valóban nincsen hozzá élő referencia. A GC következő 
futásakor tehát fel fogja szabadítani az objektumhoz tarto- 
zó memóriaterületet. 

Tekintsük át még egyszer, milyen eseményekből áll egy 
Finalize metódust tartalmazó objektum élete: 

mum Az objektum születésekor referencia kerül a 
Finalization gueue-ba. 

m Ha a GC futásakor a programunk nem tartalmaz élő 
referenciát az objektumra, akkor ez a referencia átke- 
rül a Freachable gueue-ba. 

mu A Finalize metódusokat végrehajtó speciális prog- 
ramszál a Freachable gueue-ban lévő referencia 
alapján meghívja az objektum Finalize metódusát, és 
törli a sorból a referenciát. 

mu A rKkövetkező GC-futás felszabadítja az objektum me- 
móriaterületét. 


A mintaprogram Finalization gueue menüpontja segítségé- 
vel megfigyelhetjük a GC osztály két statikus metódusának 
hatását. A GC.ReRegisterForFinalize(obj) metódus segít- 
ségével objektumreferenciákat adhatunk a Finalization sor- 
hoz, a GC.SuppressFinalize(obj) metódussal pedig a para- 
méterként átadott referenciát eltávolíthatjuk a sorból. 


a 


static void Final() ( 
Szemet obj -— new Szemet("0O"); 
GC.ReRegisterForFinalize(obj); 
GC.ReRegisterForFinalize(obj); 
Console.WriteLine("Az objektum két újabb 
4 referenciát adjuk a Finalization 
b  gueue-hoz"); 
obj - null; 
Collect(); 
WaitPendingFinalizers(); 
Console.WriteLine("A Finalize metódus 
b háromszor futott le."); 
Console.WriteLine("-----"); 
obj - new Szemet("0"); 
GC.SuppressFinalize(obj); 
Console.WriteLine("Az objektum referenciáját 
4 eltávolítjuk a Finalization gueue-ból"); 
obj-null; 
Collect(); 
WaitPendingFinalizers() ; 
Console.WriteLine("A Finalize metódus 
$ egyszer sem futott le."); 
, 





Ha egy adott objektum referenciája többször szerepel a 
sorban, akkor Finalize metódusa is többször fog lefutni 
(normál alkalmazás esetén ez természetesen nem megfe- 
lelő viselkedés), ha pedig eltávolítjuk a referenciát, a metó- 
dus nem fut le egyáltalán. 


Objektumok újraélesztése 

Egy objektum újraélesztése egyszerűen azt jelenti, hogy 
annak Finalize metódusában az objektum referenciáját el- 
helyezzük egy olyan változóban, amely később az alkalma- 
zásunkbólis elérhető. Amikor az objektum Finalize metódu- 
sa elindul, élő referencia csak a Freachable sorban találha- 
tó, de a metódus lefutása után az objektum már az alkalma- 
zásból is elérhetővé válik, így a GC nem fogja megszüntet- 
ni azt. Az alkalmazás ekkor újra elérheti az objektum tag- 
változóit, és meghívhatja annak metódusait. Az újraéleszt- 
hető objektum osztályának kódja a következő: 


class UjraeleszthetoObjektum: AlapObjektum ( 
public string eletjel; 
public UjraeleszthetoObjektum(string s) 
tb. :base(s) ( 
this.nev-s; 
Console.WriteLine("Az "-inevt" objektum 
b  konstruktora fut."); 
eletjel-st": még a memóriában vagyok!"; 
7 
-UjraeleszthetoObjektum() ( 
Console.WriteLine("Az "-nevt" objektum 
b  Finalize metódusa fut."); 
App. ObjRef-this; 
€ 
) 


Az App.ObjRef az alkalmazás másik osztályában definiált 
UjraeleszthetoObjektum típusú statikus változó. Az objek- 
tummal együtt a belőle hivatkozott objektumok mindegyike 
is új életre kel. Mindenképpen figyelembe kell azonban 
vennünk, hogy az ilyen módon újraélesztett objektumok 
Finalize metódusa már lefutott, így az objektum használata 
váratlan jelenségeket okozhat. 

Ha az újraéleszthető objektum Finalize metódusába még a 
GC.ReRegisterForFinalize(this); hívást is beillesztjük, létre- 


hoztuk az , elpusztíthatatlan" objektumot. 


oO a 0 a 











Dispose és Close metódusok 
használata 

A cikk első részében láthattuk, hogy a Finalize metódusok 
nem minden esetben alkalmasak arra, hogy az erőforrások 
felszabadítását a kellő időben és sorrendben elvégezzék. 
A .NET konvenciói szerint az erőforrások felszabadítását az 
IDisposable interfészben definiált Dispose metódus meg- 
valósításával végezhetjük el. A Dispose metódus helyes 
megvalósításához a következő szempontokat kell figyelem- 
be vennünk: 

mM az összes erőforrás megfelelő felszabadítása történ- 
jen meg a metódus meghívásakor - tehát a metódus 
hívja meg az összes tartalmazott objektum és az ős- 
osztály (ha az implementálja az IDisposable inter- 
fészt) Dispose metódusát, 

mu ne okozzon problémát a metódus ismételt meghívása 
— tehát tárolnunk kell a meghívás tényét, másodszor 
már semmi tennivalónk nincs, 

mu ne okozzon (túl nagy) problémát a metódus meghívá- 
sának elmulasztása - tehát a GC által futtatott Finalize 
metódus hívja meg a Dispose-t. 

m Ha a Finalize hívja meg a Dispose-t, akkor mene- 
dzselt objektumok Dispose metódusait nem hívhat- 
juk, mert a Finalize metódusok hívásának sorrendjét 
nem ismerjük, vagyis lehet, hogy azok Finalize metó- 
dusa már korábban lefutott — tehát meg kell különböz- 
tetnünk, hogy a Dispose hívása explicit (a kódból) 
vagy implicit (a Finalize metódusból) módon történt. 

m Ha meghívtuk a Dispose metódust, akkor a memó- 
ria felszabadításával ne kelljen megvárni az ekkor 
már szükségtelen Finalize futását — tehát a Dispose 
távolítsa el az objektum referenciáját a Finalization 
gueue-ból. 


A következő osztályséma megfelel ezeknek a szempontok- 
nak, és lehetővé teszi a belőle létrehozott objektumok biz- 
tonságos felszabadítását. 


class DisposeAlap:AlapObjektum, IDisposable ( 


protected bool disposed - false 
public DisposeAlap() ( 
Console.WriteLine("A DisposeAlap 
4 osztályban megadott konstruktor fut."); 
, 
public void Dispose() ( 
Dispose(true) ; 


GC.SuppressFinalize(this); 

) 

protected virtual void Dispose(bool 
4  disposing)( 

if(!this.disposed) ( 


if (disposing) ( 
Console.WriteLine("DisposeAlap: A 


4 menedzselt erőforrások dispose 
b metódusainak hívása."); 
T. 
Console.WriteLine("DisposeAlap: A nem 
b menedzselt erőforrások felszabadítása."); 


, 


disposed — true; 


F.A "fu 1854 (HÉ 





-DisposeAlap() ( 
Dispose(false); 
) 


public void HasznosMetodus( ) ( 
if(this.disposed) ( 
throw new ObjectDisposedException( 
this.nev, "Már lefutott a dispose 
metódus! "); 
§ 


) HasznosMetodus 
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) 


Tekintsük át az osztály kódját: 

Az osztály implementálja az IDisposable interfészt, tehát 
meg kell valósítania a Dispose() metódust. Az utód osztá- 
lyok azonban már nem ezt, hanem a Dispose(bool dispos- 
ing) metódust írhatják felül. Ez a metódus két alapvetően 
eltérő szituációban hívódhat meg. Ha a kódból meghívjuk 
az objektum Dispose() metódusát, akkor a hívás true para- 
méterrel történik, ekkor, ha korábban még nem hívtuk meg 
a Dispose()-t (ezt a disposed tagváltozó tárolja), megtörté- 
nik a menedzselt és nem menedzselt erőforrások felszaba- 
dítása is. Ha azonban a Finalize hívja meg a metódust, 
false paramétert ad át, ekkor csak a nem menedzselt erő- 
forrásokat szabadíthatjuk fel, mivel a Finalize metódusban 
nem ajánlatos más objektumokra hivatkozni. 

Ha az osztályban más metódusokat (pl. HasznosMetudus) 
is definiálunk, azokban ellenőriznünk kell a disposed válto- 
zó értékét. Ha az érték true, kivétel dobásával kell jelez- 
nünk ezt a hívónak. 

Az osztályból örökített további osztályok sémája a követke- 
ző lehet: 


class DisposeObjektum : DisposeAlap ( 
public DisposeObjektum(String s) ( 
thís.nev-s; 
Console.WriteLine("A "tnevt" objektum 
B konstuktora fut."); 
) 
protected override void Dispose(bool 
$ disposing) ( 
if(!this.disposed) ( 


try ( 
Console.WriteLine("A "-inevt" objektum 
4 Dispose metódusa fut."); 


if(disposing) ( 
Console.WriteLine( "DisposeObjektum: A 
menedzselt erőforrások dispose 
metódusainak hívása."); 
h 
Console.WriteLine("DisposeObjektum: A nem 
b menedzselt erőforrások felszabadítása."); 
this.disposed — true; 
) 
finally ( 
base .Dispose(disposing) ; 
) 
) 
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Az osztály a paraméteres Dispose metódust írja felül (a má- 
sikat nem is lehet), a kódba be kell illeszteni az ősosztály- 
ban még nem használt erőforrások felszabadítását is. Ter- 
mészetesen meg kell hívnunk az alaposztály Dispose me- 
tódusát is. Paraméter nélküli Dispose és Finalize metódus- 
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ra nincsen szükség, ezekből megfelel az alaposztálytól 
örökölt változat is. 

A mintaprogramban ebből az osztályból hozunk létre pél- 
dányokat, hogy megfigyelhessük a Dispose explicit és 
implicit (a Finalize metódusból) meghívásának hatását. 

A konvenciók szerint az objektumok felszabadítását elvég- 
ző metódus neve Close abban az esetben, ha olyan erőfor- 
rásról van szó, amelyet a lezárás után szükség esetén újra 
megnyithatunk (jellemzően Open metódussal). Ilyen eset- 
ben az alaposztálynak tartalmaznia kell egy publikus (de 
nem felülírható) Close metódust, amelyet általában a para- 
méter nélküli Dispose is meghív. 


Gyenge referenciák 

(weak references) 

Ha alkalmazásunk élő hivatkozást tartalmaz valamely ob- 
jektumra, a GC természetesen meg fogja találni a hivatko- 
zást, és érintetlenül hagyja az adott objektumot. Az ilyen hi- 
vatkozást erős referenciának (strong reference) nevezzük. 
Ezzel ellentétben, a gyenge referenciával hivatkozott ob- 
jektumok által elfoglalt memória a GC futásakor felszabadul 
ugyan, addig azonban az objektumok elérhetőek marad- 
nak az alkalmazás számára. Ha az alkalmazás használni 
szeretne egy gyenge referenciával hivatkozott objektumot, 
erős referenciát kell létrehoznia hozzá. Ha ez még a GC fu- 
tása előtt történik, az objektum továbbra is elérhető marad. 
Mikor lehet erre szükség? Például akkor, ha alkalmazá- 
sunkban könnyen rekonstruálható, de sok memóriát foglaló 
adatstruktúrákat használunk. Ha az alkalmazást a felhasz- 
náló vezérli, nem tudhatjuk, hogy a létrehozott adatstruktú- 
rára hányszor és mennyi ideig lesz még szükség. Nem tud- 
hatjuk tehát, hogy az objektumot mikor lenne célszerű el- 
dobni, illetve meddig kellene megtartani a nagy memória- 
foglalás ellenére is. 

Ezt a helyzetet kezelhetjük igen egyszerűen és hatékonyan 
a gyenge referenciák felhasználásával. Az adatstruktúra 
létrehozása és használata után létrehozzuk a gyenge refe- 
renciát, majd egyszerűen eldobhatjuk az erős referenciá- 
kat. Ha alkalmazásunk ezután nem kerül memóriaszűkébe, 
a GC nem fog begyűjtést kezdeni, tehát az adatstruktúra 
által elfoglalt memória érintetlen marad. Amikor újra szük- 
ség lesz az objektumra, új erős referenciát kérhetünk hoz- 
zá, nem kell újra létrehoznunk azt. Természetesen ha az al- 
kalmazás túl sok memóriát használ, a GC felszabadítja az 
elfoglalt memóriaterületet. 

A WeakReference osztálynak két konstruktora van: 


WeakReference(Object target); 
WeakReference(Object target, Boolean 
$ trackResurrection) ; 


A target paraméterben adhatjuk meg azt az objektumot, 
amelyre a referencia mutatni fog, a második paraméter ér- 
téke pedig azt határozza meg, hogy helyreállítható legyen- 
e a hivatkozott objektum erős referenciája a Finalize metó- 
dus futása után is. Az első konstruktor a trackResurrection 
paraméter értékét false-ra állítja, általában csak ilyen gyen- 
ge referenciák létrehozásának van értelme. Az újraélesz- 
tést nem támogató gyenge referenciákat rövid gyenge re- 
ferenciának (short weak reference), a másik típust pedig 
hosszú gyenge referenciának (long weak reference) ne- 
vezzük. 
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Ha az objektumnak nincs Finalize metódusa, akkor a két tí- 
pus pontosan egyformán viselkedik. A gyenge referencia 
létrehozása után törölnünk kell az objektum valamennyi 
erős referenciáját, különben a GC semmiképpen nem tud- 
ja felszabadítani az elfoglalt memóriát. Ha az objektumot 
újra használni szeretnénk, a gyenge referenciát erős refe- 
renciává kell átalakítanunk. Az erős referenciát a Weak 
Reference objektum Target property-je tartalmazza. Ha 
ennek értéke null, akkor a GC már felszámolta az objektu- 
munkat. 


A gyenge referenciák részletei 

Amint az már az eddigiekből is látható, a WeakReference 
objektumok viselkedése eltér a szokásos objektumokétól. A 
szokásos esetben, ha gyökérhivatkozás mutat egy objek- 
tumra, amely egy másik objektumra mutató hivatkozást tar- 
talmaz, mindkettő elérhetőnek, így a GC által érinthetetlen- 
nek minősül. Ha azonban a gyökérhivatkozás egy 
WeakReference típusú objektumra mutat, akkor az abból hi- 
vatkozott objektumot a GC memóriaszemétként kezeli. Az 
alkalmazás felügyelt heap-je két belső adatstruktúrát tartal- 
maz a gyenge referenciák nyilvántartására: a rövid gyenge 
hivatkozási táblát (short weak reference table) és a hosszú 
gyenge hivatkozási táblát (long weak reference table). A 
táblák a felügyelt heap objektumait azonosító mutatókat tar- 
talmaznak. WeakReference típusú objektum létrehozásakor 
nem történik memóriafoglalás a felügyelt heap-en (tehát ha- 
gyományos értelemben vett objektum nem is jön létre), csak 
a megfelelő referenciatáblába kerül új hivatkozás, mégpe- 
dig a konstruktor paramétereként megadott objektumrefe- 
rencia. A new operátor által visszaadott érték pedig a táblá- 
zatba felvett új referencia memóriacíme lesz. A gyenge refe- 
renciákat tartalmazó két táblázat nem része az alkalmazás 
gyökérkészletének, így az itt található hivatkozást a GC nem 
fogja figyelembe venni, eltakarítja az objektumot. 

Tekintsük át tehát újra, hogyan is történik a GC futása: 

m A GC felépíti az elérhető objektumok gráfját, az előző 
részben ismertetett módon. 

mum AGC végigvizsgálja a rövid gyenge referencia táblát. 
Ha a táblában lévő mutató olyan objektumot azonosít, 
amely nem része a gráfnak, akkor az objektum már 
nem elérhető, tehát a táblában lévő mutatót a GC 
null-ra állítja. 

m Ezután a GC a Finalization gueue-t vizsgálja végig. 
Ha olyan mutatót talál, amelynek objektuma nem ré- 
sze a gráfnak, a mutatót átmozgatja a Freachable 
gueue-ba. Ezzel egy időben az objektum felkerül a 
gráfra is, mivel újra elérhetőnek minősül. 

m Ezután a hosszú gyenge referencia tábla következik, 
ha az itt szereplő mutató olyan objektumot azonosít, 
amely nem szerepel a gráfban (ahol már a 
Freachable gueue-ban lévő mutatók objektumai is 
szerepelnek), az objektumot szemétnek minősíti, a 
mutatót pedig null-ra állítja. 

m Végül a GC a megmaradt objektumok mozgatásával 
megszünteti a címtérben maradt lyukakat. 


Ez azt jelenti tehát, hogy ha Finalize metódust tartalmazó 
objektumhoz készítünk hosszú gyenge referenciát, akkor 
objektumunk (erős referencia nélkül is) ,túléli" a GC futását, 
az erős referencia a finalizálás után is helyreállítható ma- 
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rad. Ezt a jelenséget mutatja be a mintaprogram következő 
metódusa: 


static void WeakRef() ( 
WeakRefObjektum obj — new 
b. WeakRefObjektum( "WeakRef" ) ; 


k 

WeakReference wr -— new WeakReference(obj, 
S. ELTÜE) s; 

obj -— null; 

Collect(); 


WaitPendingFinalizers(); 


obj - (WeakRefObjektum) wr.Target; 
Console.WriteLine(obj.eletjel); 


obj - new WeakRefObjektum( "WeakRef" ) ; 

wr - new WeakReference(obj, true); 

obj — null; 

GorléctÓ) s 

WaitPendingFinalizers(); 

Collect(); 

WaitPendingFinalizers(); 

obj - (WeakRefObjektum) wr.Target; 

if (obj-— null) 
Console.WriteLine("Nem sikerült a 

hi helyreállítás. "); 
else Console.WriteLine(obj.eletjel); 


A WeakReference objektum Target property-je a hivatkozá- 
si tábla megfelelő elemét (vagyis jó esetben éppen a köve- 
tett objektum mutatóját) adja vissza. Ha a visszaadott érték 
null, akkor az objektum már megsemmisült. Rövid referen- 
cia esetén a GC null-ra állítja a megfelelő tábla mutatóját, 
amint úgy találja, hogy az objektum már nem elérhető az al- 
kalmazásból. Ha az objektum tartalmazott Finalize metó- 
dust, az még nem futott le, tehát az objektum még elérhe- 
tő, de az erős referencia már nem állítható helyre a Target 
property segítségével. 

A hosszú referenciatáblában lévő hivatkozást a GC csak 
akkor törli, ha az objektum által elfoglalt memóriaterület már 
felszabadítható, vagyis a Finalize metódus már korábban 
lefutott. 


Objektumgenerációk 
Az objektumok generációkba sorolása a teljesítmény növe- 
lését (a GC futásidejének csökkentését) szolgálja. A gene- 
rációk használata a következő feltételezések alapján növel- 
heti a teljesítményt: 
mu Az újabb objektumok várható élettartama rövidebb. 
m A régebbi objektumok várható élettartama hosszabb. 
m A nagyjából egyszerre létrehozott objektumok általá- 
ban valamilyen kapcsolatban vannak egymással, az 
alkalmazás rövid időn belül fogja használni őket, és 
egyszerre válhatnak fölöslegessé 
m A heap egy részének folytonossá tétele hamarabb el- 
végezhető, mint az egész heap-é. 
Tekintsük át, hogyan és minek alapján végzi el a GC a heap 
objektumainak generációkba sorolását. 
Kezdetben a felügyelt heap nem tartalmaz objektumokat. A 
hozzáadott objektumok a 0. generációba kerülnek, egé- 


szen addig, amíg GC-futás nem történik (akár a kódból in- 
dítjuk, akár automatikusan indul a heap foglaltsága miatt). 
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A felügyelt heap az első begyűjtés előtt 


Amikor begyűjtésre kerül sor, a GC a szokásos módon 
szétválasztja a szemetet a még használható objektumoktól, 
a maradékot átmozgatja az alapcím közelébe, és ezeket 
átsorolja az 1. generációba. Tehát az 1. generációba azok 
az objektumok kerülnek, amelyek már , túléltek" egy be- 
gyűjtést. A 0. generáció a begyűjtés után üres, de a ké- 
sőbb létrejövő új objektumok természetesen ide kerülnek. 
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A felügyelt heap az első begyűjtés után 


Ha a 0. generáció megtelik, a GC újabb begyűjtést kezde- 
ményez. Ekkor az 1. generáció ,túlélői" a 2. generációba 
kerülnek, a 0. generáció megmaradt objektumai pedig az 
1. generációba. 
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A felügyelt heap a második begyűjtés után 





A .NET szemétgyűjtője jelenleg 3 generációt támogat, tehát 
a 2. generáció túlélői maradnak a 2. generációban. 

Az objektumok generációváltását a mintaprogram követke- 
ző metódusában figyelhetjük meg: 


static void Generacio() ( 
Console.WriteLine("Az objektum generációk 

4 maximális száma: (0)",GC.MaxGeneration) ; 
Szemet[] gen-new Szemet[GC.MaxGenerationt1] ; 


for (int i-O;iczGC.MaxGeneration;itt) 
gen[li]-new Szemet(i.ToString( )); 


for (int i1-0O;ic-GC.MaxGeneration;itt) ( 
Console.WriteLine("A(z) "ti.ToString()t". 
s objektum generációja:(0)", 
6 GC. GetGeneration(gen[i])): 
genli]-nuli; 
Collect(); 
WaitPendingFinalizers(); 


Amikor a heap megtelik, a GC induláskor eldönti, hogy a 
begyűjtést csak a 0. generációban, vagy a teljes heap-en 
végezze el. Mivel az új objektumok várható élettartama rö- 
vid, jó esély van rá, hogy a 0. generációban végzett be- 
gyűjtés számottevő mennyiségű memória felszabadítását 
teszi lehetővé, a teljes begyűjtéshez viszonyítva jelentősen 
rövidebb idő alatt. Ha a 0. generációból nem sikerült bizto- 
sítani a megfelelő mennyiségű tárterületet, a begyűjtés 
folytatódhat az 1. és 2. generációban. Jelentős teljesít- 
ménynövekedést okozhat az is, hogy az új objektumok min- 


dig folyamatosan, egymás utáni címeken jönnek létre. Az 
egyik feltételezésünk szerint a közel egy időben létrejövő 
objektumok szoros kapcsolatban vannak egymással, így 
általában a hozzáférés is közel egy időben történik. Mivel 
az objektumok folyamatos címtérben helyezkednek el, a 
CPU cache kihasználása optimális lehet. 


Nagy objektumok kezelése 

Szintén a teljesítményoptimalizálás a célja a nagy objektu- 
mok (több mint 20 000 byte) különálló kezelésének is. A 
nagy objektumok önálló, erre a célra fenntartott heap-en 
foglalnak memóriát. A memóriafoglalás, a Finalize metó- 
dusok futtatása és a memória felszabadítása is a már 
megismert módon történik. Elmarad viszont a memória ,tö- 
mörítése", vagyis a GC nem tölti fel a megmaradt objektu- 
mokkal az alapcímtől kezdve a címteret, megmaradnak a 
törölt objektumok helyén keletkezett lyukak. Ennek oka az, 
hogy a nagy objektumok mozgatása túl sok CPU-időt ven- 
ne igénybe. 


A GC monitorozása 

A GC működésének valós idejű monitorozására számos 
teljesítnényszámláló szolgál, amelyek megjelenítésére a 
System Monitor ActiveX kontroll szolgál. A System Monitort 
legegyszerűbben a PerfMon.exe futtatásával indíthatjuk el. 


Számláló hozzáadása gi 


(C Helyi számlálók használata 
(s Más számítógép számlálót 










MPC2151 . 
Teljesítményobjektum: 
NET CLR Memory r] 


C Minden számláló 


(a Számlálók választása listából 


Allocated Bytes/sec 
Finalization Survivors 
Gen 0 heap size 

Gen 0 Promoted Bytes/Sec — 
Gen 1 heap size 

Gen 1 Promoted Rutes/Sec 


C Minden példány 
(ő Példányok választása listából: 
Global 



















Teljesítményszámláló hozzáadása 


A GC-hez tartozó számlálókat a .NET CLR Memory objek- 
tum kiválasztásával érhetjük el. Ezután ki kell választanunk 
a megfigyelni kívánt alkalmazást és a megfelelő számláló- 
kat a grafikonok megjelenítéséhez. 
SZERÉNYI LÁSZLÓ 
szerenyi .lomet.bu 





A cikkben szereplő URL-ek: 
[1] http:/ / store.netacademia.net/ mshu/ other/ technet. code/ gc.zip 
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ASR.NET 2.0 (vvVhidbey) 


Mi VÁRHATÓ A 2005-ös ASP.NET-BEN? I. RESZ 


ADATELÉRÉS, ADATFORRÁS-VEZÉRLŐK, GRIDVIEW 


Cikksorozatot indítunk a . NET Framework következő ge- 


nerációjáról, amelynek Vhidbey a kódneve. Az első három 





részben az ASPRP.NET-ről lesz szó, aztán az ADO.NET-ről, 


majd a . NET Framework egyéb újdonságairól. 


ASP.NET 2.O 

Miben különbözött az ASP.NET az ASP-től? Mindenben. Az 
ASP.NET-fejlesztők egy teljesen új architektúrát dolgoztak 
ki dinamikus webtartalom előállítására, amely a lehető leg- 
jobban igyekszik kihasználni a .NET Framework képessé- 
geit. Radikális váltás volt, és három év használat után el- 
mondható, hogy igen jól sikerült a keretrendszer. Egy ilyen 
start után a fejlesztőknek nehéz felül- Hi Me 


múlniuk saját magukat. Ezért a 2.0 

nem lesz radikálisan más, sőt a fej- 

lesztők szándéka szerint felülről kom- E 

patibilis lesz az 1.1-es verzióval. Azaz 

nem kell készülni hatalmas váltásra, Ea 

inkább arra, hogy rengeteg új szolgál- 

tatást fogunk kapni, amelyeket nekünk HL 

kellett megírni az 1.1-ben. Az erős ala- 

pot most kiegészítik számtalan kényelmi szolgáltatással, 
valamint most van idejük sok, eddig elhanyagolt terület (pl. 
többnyelvű GUI) kidolgozására. 

Csak az ASP.NET legalább 2000 új típust fog tartalmazni az 
előző verzióhoz képest, ez jelzi a fejlesztések volumenét! 


VS.NET Community Technology 
Preview 2004. március 

Erre a verzióra épülnek a cikkünkben látható példakódok. 
Nem is annyira a VS.NET a mérvadó, hanem, hogy az e 
verzióval járó .NET Frameworkre építettem a példákat. Ver- 
ziószám: 2.0.40301. 

Egy alfa fázisban járó termékről van szó, amely várhatóan 
csak 2004 nyarán lép át a béta státusba, azaz egyes metó- 
dusok vagy objektumok még könnyen változhatnak. A cikk 
írása közben a 2003. őszi verzióra írt példáimat jelentősen 
át kellett dolgoznom, annyit változott még a termék, remé- 
lem ez a változat már közelebb áll a végleges formához. 
Csapjunk hát bele! 


Adatelérő vezérlők és GridView 

Az adatbázisok használata mindig is kiemelt fontosságú volt 
a webalkalmazások írása során. Az 1.1-ben pár sornyi kód- 
dal könnyen lehetett adatbázisokkal kommunikálni. A koráb- 
bi próbálkozásokkal ellentétben a databinding, azaz a vi- 
zuális vezérlők adatokhoz történő deklaratív hozzákötése 
valóban használható volt, de csak egy irányban. Azaz 





Csak az ASP.NET 
legalább 2000 új 


típust fog tartalmazni! 


könnyedén meg tudtunk jeleníteni csak olvasható módon 
adatokat például egy TextBoxban, de a lap felbpostázásakor 
a databinding nem tudta visszaírni a változtatásokat az 
adatbázisba. A jó hír, hogy a 2.0-ban ez már működik. 
Ráadásul olyannyira automatizálták a folyamatot, hogy egy 
árva kódsor leírása nélkül is működik a kétirányú adatkötés! 
Persze azért deklaratívan le kell írni, milyen adatokat és ho- 
vá szeretnénk mozgatni. Ezt az aprólé- 
kos, unalmas munkát ügyesen tudja 
automatizálni a Visual Studio .NET. Ha 
például a Server Explorerből rádobunk 
egy adatbázistáblát egy WebFormra, 
akkor azonnal kapunk egy táblázatos 
nézetet, amely élő adatbázis-kapcso- 
lattal rendelkezik, azaz nemcsak meg- 
mutatja a tábla tartalmát, hanem még 
módosítani is lehet azt (INSERT, UPDATE, DELETE). 

No de lássuk ezt részleteiben! Először is azt kell átgondol- 
nunk, hogy még ha meg is akarjuk úszni kód nélkül a bulit, 
az adatbázis-elérés részleteit akkor is le kell írni valahol. Ez 
lesz az aspx lap, a WebForm. Kell valaki, aki a felpostázott, 
módosított tartalmat elkapja, ezért kell egy olyan vezérlő, 
amely képes kommunikálni az adatbázissal, és kiolvassa a 
hozzákapcsolt vezérlő adatait. Ezek az új Data Source 
Controlok. (Az persze joggal kritizálható, hogy egy ilyen 
GUI-ba gyömöszölt adatelérés korrekt megoldásnak tekint- 
hető-e. Szerintem csak nagyon egyszerű alkalmazásoknál 
helyes így dolgozni.) 

Példánkban termékkategóriánként listázzuk ki a terméke- 
ket. A kategóriákat egy legördülő lista tartalmazza, amely- 
ben kategóriát váltva az alsó grid automatikusan frissül, 
a kiválasztott ételtípust megjelenítve: 
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Célunk, hogy a termékek adatai módosíthatók is legyenek, 
illetve legyen módunk törölni a nemkívánatos sorokat. 
Mindez kód nélkül? Igen. Lássuk, hogyan! 

Első lépésként deklaráljuk a lap fejlécét: 


2408 page language—"Ctt" 
compilewith-"Default.aspx.cs" 
classname-"NetAcademia.Default aspx"92 


Látható, hogy nem src, hanem compilewith attribútum hi- 
vatkozik a háttérkódra, és nem inherits, hanem classname 
mutatja meg a mögöttes osztály típusát. (Most ugyan nem 
lesz háttérkódunk, de nem árt látni, itt mi változott.) Azért 
változtak az elnevezések, mert megváltozott a feldolgozási 
modell. Eddig az ASPX elemző által generált osztályt le- 
származtatták az inherits-ben megadott saját code behind 
osztályunkból. Így tudtunk együttműködni az aspx lappal, 
valamint így tudott a VS.NET tervezője kódot injektálni a 
háttér forráskódunkba. Ezen megoldás nagy hátránya, 
hogy a Designer firkálgat a mi kódunkba, ami néha koníflik- 
tusokat okoz (az a Ot$! designer kitörölte a kódomat). Per- 
sze oda van írva, hogy ne bántsuk azt a bizonyos kódrész- 
letet, mert az a designer felségterülete, azért mindig van- 
nak felfedező kedvű emberek. 

A 2.0 fordítási modellje teljesen más. Mind Ct-ban mind 
VB.NET-ben bevezetik a partial, azaz részleges osztályo- 
kat. Ez lehetővé teszi, hogy egy osztály tartalmát tetszőle- 
ges számú forráskódban írjuk meg, amelyeket majd a fordi- 
tó gyúr egybe. Ezt az ASP.NET (és a WinForms is) úgy 
használja ki, hogy az ASP.NET parser és a VS.NET által ge- 
nerált kód is a mi háttérkódunktól független, külön fájlba ke- 
rül. Nem is látjuk ezeket! Ebben az esetben szó nincs sem- 
miféle öröklésről, hanem egyszerűen a mi kódunkat hozzá- 
fordítják a generált kódhoz. Ezért a 2.0-ban már nem Code 
Behind, hanem Code Beside technológiáról beszélünk. 
Például az előbbi fejléchez ez a részleges code beside 
osztály passzol: 


using System; 

namespace NetAcademia ( 

public partial class Default aspx ( ) 
, 


De térjünk rá az adatelérésre! A felül látható legördülő lista 
így hozható létre: 


casp:dropdownlist id-"CategoryList" 
runat-" server" 
datasourceid-"CategoryDataSource" 
datavaluefield-"CategoryID" 
datatextfield-"CategoryName" 
autopostback-"True": 
£/asp:dropdownlist? 


Ami új, az a datasourceid jellemző. Itt egy Data Source 
Controlt kell megadni. Esetünkben ez egy SalDataSource 
lesz, amellyel SOL Server vagy bármilyen egyéb relációs 
adatbázis adatait tudjuk kezelni: 


casp:sgldatasource 
id-"CategoryDataSource" 
runat-"server" 
selectcomnand— 


"SELECT CategoryID, CategoryName, 
Description, Picture 

FROM dbo.Categories" 
insertcommand-— 

"INSERT INTO Categories( 
CategoryName, Description) 
VALUES (?, ?)" 

updatecommand— 

"UPDATE Categories SET 
CategoryName — ?, 

Description — ? 

WHERE (Categories.CategoryID — ?)" 
deletecomnand— 

"DELETE FROM Categories 

WHERE (Categories.CategoryID — ?)" 
providername-"System. Data. OleDb" 
connectionstring- 
"Provider-SOLOLEDB.1; 

Integrated Security-SSPI; 

Initial Catalog-Northwind; 

Data Source-(10cal);" 
datasourcemode-"DataSet" 
cacheduration— "60" 
enablecaching-"True"? 
£/asp:sgldatasource? 


Az attribútumok zöme triviális, ami érdekes, az a három 
utolsó. A datasourcemode azt adja meg, hogy az adatel- 
érés DataSet vagy DataReader alapú legyen-e. A 
DataReader nyilván valamivel gyorsabb, de nem lehet se 
szűrni, se cache-elni, se rendeztetni a kimenetet. (Módosí- 
tani lehet, mert arra ott vannak az SOL-parancsok, amiket 
közvetlenül végre tudnak hajtani.) 

DataSet esetén az utolsó két attribútummal maximum 60 
mp-ig tartó cache-elést állítottunk be. Azaz ha van elég sza- 
bad memória a cache manager részére, akkor a lekérde- 
zést nem kell megismételni 60 mp-ig. Ami külön izgalmas, 
hogy meg lehet adni adatbázistartalom-függő cache-elést 
is, amit az Sg/ICacheDependency attribútummal lehet sza- 
bályozni. (Erről bővebben a sorozat következő cikkében.) 
A kategórialista feltöltve. Amikor felpostázódik a tartalma, 
le kellene szűrni a termékeket a kiválasztott CategoryID 
alapján. Ez már nagyon kódszagú feladvány, de nem az 
adatelérő vezérlőkkel! Lássuk csak: 


casp:sgldatasource 
id-"ProductDataSource" 
runat-"server" 
selectcommand— 

"SELECT ProductID, ProductName , 
AduantityPerUnit, UnitPrice, 
UnitsInStock, UnitsOnOrder, 
ReorderLevel, Discontinued 
FROM dbo.Products 

WHERE CategoryID — ?" 
insertcommand— 

"INSERT INTO Products 
(ProductName, SupplierID, 
CategoryID, RNuantityPerUnit, 
UnitsIinStock, UnitsOnOrder, 
ReorderLevel, Discontinued) 





VALUES EGG Etss EG KE els ZLÜRTDJÁT 
updatecommand— 

"UPDATE Products SET 

ProductName -— ?, NuantityPerUnit — ?, 
UnitsInStock ?, UnitsOnOrder — ?, 
ReorderLevel — ?, Discontinued — ? 
WHERE (Products.ProductID — ?)" 
deletecommand— 


200 a o 3. 
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"DELETE FROM Products 
WHERE (Products.ProductID — ?)" 
providername-"System. Data . OleDb" 
connectionstring- 
"Provider-SOLOLEDB.1; 
Integrated Security-SSPI; 
Initial Catalog-Northwind; 
Data Source-(10ocal) ; "7 
sSselectparameters? 
casp:controlparameter 
name—-"?" 
propertyname-"SelectedValue" 
type-"Int32" 
controlid-"CategoryList"? 
c€/asp:controlparameter? 
c/selectparameters? 
£/asp:sgldatasource? 


Az adatelérő vezérlőben megadhatunk paramétereket, 
amelyeket postback esetén automatikusan kiolvas a vezér- 
lő, és a paraméterektől függően hajtja végre a selectcom- 
mand-ban tárolt parancsot. Esetünkben a CategoryList ve- 
zérlő (a korábbi lista) SelectedValue jellemzőjét olvassa ki, 
amelyet a WHERE CategoryID - ? feltételben a ? helyére 
helyettesít be. Stringművelettel? Természetesen nem. A 
mai paranoiás világban nem szabad SOL Stringeket ra- 
gasztgatni házi barkácsmódszerekkel. Az alábbi parancs 
figyelhető meg az SOL Profilerben, ha kiválasztjuk a 2-es 
ID-jű termékkategóriát: 


exec sp executesgl 

N"SELECT ProductID, ProductName , 
FROM dbo.Products 

WHERE CategoryID - eEP1", 

N"eP1 int", 2 


Ember legyen a talpán, aki így a parancsba be tud injektál- 
ni plusz sal kifejezést! (A tudomány mai állása szerint nem 
lehet.) Paraméterforrás lehet vezérlő tetszőleges jellemző- 
je, guerystring, form paraméter, session változó vagy cook- 
ie érték is. Már csak egy lépés van hátra, meg kell mutatni 
a leszűrt sorokat. Erre egy új vezérlőt veiünk be, amelynek 
GridView a becses neve. Ez a mostani DataGrid felturbó- 
zott változata: 


casp:gridview 
id-"ProductGridView" 
runat-"server" 
autogeneratecolumis-"False" 
datasourceid-"ProductDataSource" 
datakeynames-"ProductID" 
allowpaging-"True" 
pagesize-" 
allowsorting-"True" ...: 
ccolumnsz 
casp:boundfield 
sortexpression-"ProductName" 
datafield-"ProductName" 
headertext-"ProductName" /2 
casp:boundfield 
sortexpression-"UnitPrice" 
datafield-"UnitPrice" 
readonly- 
headertext-"UnitPrice" /? 
casp:checkboxfield 
sortexpression-"Discontinued" 
headertext-"Discontinued" 
datafield-"Discontinued" /2 
gSasp:commandfield 














showdeletebutton-"True" 
showeditbutton-"True" /2 
casp:hyperlinkfield 
datanavigateurlformatstring- 
"Details.aspx?id-(0)" 
datanavigateurlfields-"ProductID" 
text-"Details" /2 
c£/columsz 
cpagersettings 
mode-"NumericFirstLast" /? 
c/asp:gridview? 


A formázáshoz kapcsolódó sorokat kidobtam a kódból, az 
élő példákban [1] természetesen benne vannak. Látható, 
hogy a datasourceid a szűrt terméket generáló adatforrás- 
ra utal, a datakeynames pedig a forrás DataSet elsődleges 
kulcsot tartalmazó oszlopát azonosítja. De miért érdekli ez 
a gridet? Nos, az update és delete műveletekhez meg kell 
ragadni a kérdéses sort, és ehhez szükség van a kulcs ér- 
tékére. Látható, hogy kértünk rendezést és lapozást is. 
Mindkettőt DataSet, illetve DataView szinten oldják meg, 
ami messze nem tökéletes megoldás. Nagyszámú sor ese- 
tén elfogadhatatlan, hogy 100000 sor leugrik a webformra, 
amiből aztán pár sort kivéve mind eldobják. Az ADO.NET 
2.0-ban bevezettek az SgiCommand objektumon egy 
ExecutePageReader metódust, amivel korrektül, szerverol- 
dali kurzorokkal tényleg csak a szükséges sorokat hozzák 
le. Sajnos azonban ebben a verzióban a GridView még 
nem használja ki ezt a lehetőséget (vagy én nem vettem 
észre, hogy kihasználja). A pletykák szerint ez a lapozós 
ADO.NET szolgáltatás ki is marad a végleges 
Frameworkből. Majd meglátjuk jövőre. 

Egy kicsit spékeljük meg a példánkat. Gyakori igény, hogy 
azokat az értékeket, amelyek egy fix, diszkrét, véges hal- 
mazból kerülnek ki, listából választhassuk ki, ne kelljen be- 
írni. Esetünkben a termék kategória ilyen. Szerkesztő né- 
zetben ezt szeretnénk látni: 


as 


4 kásehottn Tan 





Kibővített szerkesztőfelület kategórialis- 
tával 


Normál nézetben természetesen csak a kategória neve lát- 
szik, lista helyett statikus szövegként. Az új funkcióhoz a 
grid adatforrását kissé át kell konfigurálni: 


selectcommand-— 

"SELECT ProductID, ProductName , 
ANduantityPerUnit, UnitPrice, 
UnitsInStock, UnitsOnOrder, 
ReorderLevel, Discontinued, 
CategoryName, Products.CategoryID 
FROM dbo.Products 

INNER JOIN Categories 

ON Products.CategoryID -— 
Categories.CategoryID 

WHERE Products.CategoryID — ?" 


A listázó megjelenítéshez fel kell oldanunk a 
Products.CategoryID mező értékét a tényleges kategória- 


névre és a CategoryID értékére is szükségünk lesz, hogy 
be tudjuk állítani a legördülő listát a termékhez tartozó ka- 
tegóriasorra. A CategoryID-t belevesszük az updatecom- 
mand-ba: 


updatecommand— 
"UPDATE Products SET 
CategoryID — ?, 


ProductName - ?, OuantityPerUnit — ?, 
UnitsIlnStock -— ?, UnitsOnOrder — ?, 
ReorderLevel — ?, Discontinued — ? 


WHERE (Products.ProductID — ?)" 


A plusz oszlop megjelenítését végző sablon: 


sSasp:templatefield: 
cheadertemplaterCategory 
c/headertemplate?z 
citemtemplatez 
sSsasp:label headertext-"Category"? 
c9tt Eval("CategoryName") 962 
c/itemtemplatez 
csedititemtemplatez 
casp:dropdownlist id-"CategoryListForUpdate" 
runat-"server" 
datasourceid-"CategoryDataSource" 
datavaluefield-"CategoryID" 
datatextfield-"CategoryName" 
selectedvalue- 
" c96tt Eval("CategoryID") 92" 
A 
c/edititemtemplate? 
c/asp:templatefield? 


A példa egyúttal azt is demonstrálja, hogy a databinding ki- 
fejezések jelentősen egyszerűbbek lettek. 


ASP.NET 1.1: 
cXtt DataBinder.Eval(Container.Dataltem, 
"CategoryID") 962 


ASP.NET 2.0 
tt Eval("CategoryID") 92 


Listázás nézetben a Label látszik, szerkesztő nézetben a 
lista. Így már érthető, miért kellett a plusz két oszlop a 
selectcommandt-ba. Zárásul már csak egy lépés van hátra. 
Az updatecommand-nak meg kell mondani, hogy az első 
paraméter, a CategoryID értékét a kategórialistából felpos- 
tázott értékből helyettesítse be. Ezt is megúszhatjuk kód 
nélkül, köszönhetően a paraméterezhető szűrési lehető- 
ségnek: 


cupdateparameters? 
casp: formparameter 
name-"?" 
type-"Int32" 
formfield- 
"ProductGridView$ ctl3$CategoryListForUpdate": 
c€/asp:formparameter? 
c/updateparameters? 


A megoldás egyetlen szépséghibája a lista id-ja (form- 
field). A gridbe ágyazott DropDownList generált kliensolda- 
li neve kiolvasható a vezérlő ClientiD tulajdonságából, de 


ehhez meg kellene szerezni a vezérlőre mutató referenciát. 
Ez már több kód, mint amit egy databinding kifejezés esz- 
tétikusan elbír, ezért ezt már háttérkódba kellene írni (ettől 
most eltekintünk). 

Még két kérdést szeretnék megválaszolni. Miért OLEDB? 
Miért nem natív SOL Serveres osztályok? Egyszerűen 
azért, mert ez az alfa verzió az OLEDB providerekkel még 
simábban működik, mint az SOL-essel. De gondolom, a 
béta verzióban már át tudom írni a kódot SOL Server spe- 
cifikusra. A másik, hogy mivel egyszerűbb így deklaratívan 
leírni mindent, nem lenne egyszerűbb programsorokkal ki- 
fejteni, mit is akarunk csinálni. Nos, kézzel valóban elég ki- 
ábrándító a fenti sorokat beírni. De itt jön a képbe egy jó 
IDE. A VS.NET a fenti kódot 9996-ban képes legenerálni. A 
deklaratív módszer pont a kódgenerátoroknak kedvez, 
amelyek valamely programnyelven sokszor csak nehezen 
karbantartható módon tudnak kódot írni, a szabályosabb 
xmi! leírás sokkal könnyebben megfogható a varázslókkal. 
Szóval elmondhatjuk, hogy a fenti megközelítés inkább va- 
rázsló, mint emberbarát. 


A DetailsView vezérlő 

A GridView egyszerűen használható eszköz sok sor meg- 
mutatására. Sok oszlop esetén azonban problémás a meg- 
jelenítés és a szerkesztés is a túl hosszú sorok miatt. Rá- 
adásul a rengeteg adatban elveszik a felhasználó szeme. 
A DetailsView egy rekordot mutat meg, minden egyes osz- 
lopát egy új táblázatsor TextBox-ában vagy egyéb vezérlő- 
jében (pl. CheckBox). Sajnos a 2003. őszi verzióban még 
jól működő vezérlőben olyan, nem dokumentált változtatá- 
sokat eszközöltek, amely miatt a 2004. márciusi .NET 
Framework alatt nem tudtam működőképessé tenni a ko- 
rábbi példáimat. 


Az ObjectDataSource adatforrás 
Nagyon jól látszik, hogy a DataSet alapú modell mellé egy- 
re erősebben kezd felsorakozni az üzleti objektum alapú 
adatkezelés. Ebben az esetben nem DataRow objektumok 
reprezentálják az üzleti információt, hanem általunk írt osz- 
tályokból létrehozott objektumok, amelyek tagváltozókban 
tárolják az általában adatbázisból származó adatokat. Eb- 
ben a modellben az üzleti logikát az osztály, entitás metó- 
dusaiban implementáljuk. 

A modellt támogatandó lesz egy ObjectDataSource nevű 
adatforrás. Hasonlóan a korábban látott Sg/DataSource- 
hoz, ez is forrása lehet DataBound vezérlőknek. Az 
ObjectDataSourcett fel kell paraméterezni, hogy az adatel- 
érő réteg mely metódusaival képes a select, insert, update 
és delete utasításokat végrehajtatni. Ha sikerül használha- 
tó dokumentációt fellelni, akkor a cikksorozat következő ré- 
szében bemutatom e vezérlő használatát is. 


SOCZÓ ZSOLT 
zsolt.soczogynetacademia. net 
ASP.NET MVP, MCSE. MCSD. MCDBA. MCT 








A cikkben szereplő URL-ek 


[1] http:// www.netacademia.net/ tudastar/ default.asp?upid-2656 
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vVvVi-ndovwvs 


szolgáltatások 


NI AUTHORITYWNNETWORKSERVICE 


A sorozat előző részében a L ocalService fiók nevében 


futó szolgáltatásokat pécéztük ki, most a másik, 


a LocalSystem fiók használatának mértékéhez képest 


törpe minoritásnak számító NetworkService 


fiókhoz köthető szervizek kerülnek a fókuszba. 


A második 9 

Ebben a részben összesen 9 szervizt vizsgálunk meg. Azo- 
nos csoportba sorolásuk oka, hogy mind az újonnan (Win- 
dows XP, Windows Server 2003) bevezetett NetworkService 
(Hálózatszolgáltatás) fiókkal működnek, amelyről a korábbi 
részek alapján már tudnunk kell egy-két dolgot, de azért 
nézzük meg a tulajdonságaikat röviden újra: 

m gyengített jogosultsági körrel futnak, ami körülbelül 
megfelel egy átlagos felhasználói fiók lehetőségeinek, 
de úgy, hogy közben a helyi erőforrásokhoz alig van 
jogosultságuk, 

mu a hétköznapi értelemben vett erőforrás-hozzáférés 
(például objektumokhoz) nem megengedett, 

m az ezzel a fiókkal futó szolgáltatások az adott számító- 
gépfiók (Computer Account) hitelesítő adatai segítsé- 
gével érik el a hálózati erőforrásokat, 

m és végül ehhez a fiókhoz sincs jelszó hozzárendelve. 


A számítógépfiók 

Azt ugye tudjuk, hogy minden számítógépet, amelyen a 
Windows NT/2000/XP vagy a Windows Server 2003 fut, 
egyértelműen lehet azonosítani egy egyedi számítógépfiók- 
kal is. Ezt a fiókot a felhasználói fiókokhoz hasonlóan hitele- 
sítésre és naplózásra is lehet használni egy tartományban 
vagy egy hálózatban. Természetesen akkor is létezik a szá- 
mitógépfiók, ha a gép nem tagja egy tartománynak, de az 
biztos, hogy a tartományvezérlő (ha több van, akkor az a 
tartományvezérlő, amelyik a RID, azaz a Relative Identifier 
Master szerep birtokosa) a tartományba lépéskor ezt frissíti. 
Ennek a fióknak a neve (gépnévő$), és a szintén ekkor gene- 
rált jelszava segítségével fog ezután a gép belépni a tarto- 
mányba, még a felhasználói belépés előtt. Ez a belépés az- 
tán rezidens marad, nem is kell például az adott gépen tör- 
ténő felhasználó kilépésekor megújítani (bár egy alkalom- 
mal azért lezajlik automatikusan a háttérben az újrahitelesí- 
tés: ha definiáljuk az SMB kapcsolat leválasztást a Csoport- 
házirendben). Száz szónak is egy a vége, ezt a fiókot és a 
jelszavát használja az operációs rendszer a következő szer- 
vizek futtatására: 

u DHCP Client 
m Distributed Transaction Coordinator 


DNS Client 

FTP Publishing Service 

License Logging 

Performance Logs and Alerts 

Remote Procedure Call (RPC) Locator 
Simple TCP/IP Services 

Windows Media Services 


DHCP Client (DHCP-ügyfél) 

A szerviz rövid neve: Dhcp 

Az alkalmazás neve: dhcpcsvc.dll (svchost.exe) 

Függés: AFD Networking Support Environment, TCPAP 

Protocol Driver, IPSEC Driver 

Függesztés: WinHTTP Web Proxy Auto-Discovery Service 

Porthasználat: TCP: 68; UDP: 67, 68, 1029 

Alapértelmezett indítás: automatikus 

A DHCP-ügyfél neve kicsit félrevezető, anno furcsa is volt, 
hogy miért is fut automatikusan a fix IP-címmel ellátott szerve- 
ren ez a szolgáltatás. Ám aki leállítja, annak szintén fura, vagy 
inkább megrázó élményben lesz része, mivel a DHCP- 
szerverrel való mindennemű kapcsolattartás mellett az IP- 
címek regisztrálását és DNS-adatok frissítését is ez a szerviz 
intézi. Ez a folyamat a rendszerindítás után következik, pél- 
dául egy DHCP-kliens gépnél rögtön a DHCP-adatok megér- 
kezése után, de néhány más esemény is kiválthatja, úgymint: 

m a kliens IP-címének hozzáadása, megváltoztatása 
vagy törlése, 

m az IP-cím élettartamának változása (pl. a gép újraindi- 
tása) vagy az TCP/IP konfiguráció újraépítése (ipcon- 
fig /renew), 

m a kliens adatainak manuális frissítése a dinamikus 
DNS engedélyezése esetén (ipconfig /registerdns), 

m tagkiszolgáló előléptetése tartományvezérlővé. 

Ha a szervizt leállítjuk, a fentiek értelmében nem lesz ered- 
ményes kapcsolatunk a DHCP-szerverrel (ergo muszáj ma- 
nuálisan konfigurálni a TCP/IP-t, vagy jön az APIPA), és a di- 
namikus DNS-frissítés sem fog működni. Ha a gépünk DNS- 
szerver is egyben, akkor ilyenkor a jól ismert zónaeltávolí- 
tást és -visszaállítást sem tudjuk alkalmazni (net stop/start 
netlogon). És még sorolhatnánk. .. Ha esetleg le is tiltjuk, ak- 
kor a kapcsolódó (az előző számban tárgyalt) WinHTTP 


Web Proxy Auto-Discovery szolgáltatás sem fog rendelke- 
zésre állni. De nem éri meg kézi indításúra állítani sem, mert 
(ellentétben néhány másik társával) ez a szerviz nem fog 
elindulni automatikusan, ha szükség lesz rá. 


Distributed Transaction Coordinator 
(Elosztott tranzakciók koordinátora) 

A szerviz rövid neve: MSDTC 

Az alkalmazás neve: msdtc.exe 

Függés: Remote Procedure Call, Security Accounts Ma- 

nager 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: automatikus 
Üzemeltetők körében talán nem a mindennaposan emlege- 
tett szolgáltatások körébe tartozik a DTC, pedig néhány te- 
rületen igencsak fontos, igencsak rá épül jó pár más kiszol- 
gáló alkalmazás, mint például az SOL Server, a BizTalk 
Server, a Commerce Server, vagy például a Message Oueue 
Server. De használatos számítógéprendszerek, állomány- 
rendszerek közötti tranzakciók kezelésére is. A DTC a 
Component Services része (korábban Microsoft Transaction 
Server-ként volt ismert) és a külső, úgynevezett kétfázisú 
tranzakciók irányítója. Ha leállítjuk vagy letiltjuk, akkor a fen- 
ti alkalmazásokon kívül mindazon megoldásokkal lesznek 
menedzselési problémáink, amelyek a COM-t- technológiát 
használják. 





DNS Client (DNS-ügyfél) 

A szerviz rövid neve: Dnscache 

Az alkalmazás neve: dnsrslvr.dil (svchost.exe) 

Függés: TCPAP Protocol Driver, IPSEC Driver 

Függesztés: — 

Porthasználat: TCP: 53 

Alapértelmezett indítás: automatikus 
Ennek a szolgáltatásnak a lényege valószínűleg értelem- 
szerű mindenki számára: a kliensoldali névfeloldásról és a 
DNS-adatok gyorsítótárazásáról van szó. A DNS-ügyfél- 
szerviz a következő szolgáltatásokat nyújthatja egy kliens 
(mármint a DNS szempontjából kliens) gépen: 


Teljes körű gyorsítótárazás 

A lekérdezések eredményéből adódó erőforrásrekordok a 
kliens gyorsítótárába tárolódnak, majd onnan újrafelhaszná- 
lásra is kerüllhetjnek, persze a TTL (Time to Live - élettar- 
tam) értékének függvényében. 


RFE kompatibilis negatív gyorsítótárazás 

Kibővítve a szimpla gyorsítótárazás funkcióját a DNS-ügyfél 
képes arra is, hogy a lekérdezésekre kapott hibás válaszo- 
kat is eltárolja. De miért kell eltárolni a hibás bejegyzéseket? 
A magyarázathoz tudnunk kell a módszer lényegét. Arról 
van szó, hogy negatív választ akkor kap a kliens, ha az adott 
névhez nem tartozik erőforrásrekord. Ilyenkor ezt is elteszi a 
gyorsítótároba, de megjelöli negatívként, és erről a , skarlát 
betűről" tudni fogja a következő alkalommal (ami akár má- 
sodpercek múlva is lehet), hogy az adott gép felé menő le- 
kérdezéssel már nem kell bajlódni, hiszen nem ér semmit. 
Persze itt is van élettartam, sőt rövidebb is (maximum 5 
perc), mint a helyes címek esetén, hiszen előfordulhat, hogy 
az az összerendelés, ami pár perce még nem volt használ- 


ható, mostanra már értékes rekorddá nőtte ki magát. Ez a fo- 
lyamat egyébként a 2308-as számú RFC dokumentum alap- 
ján működik [1]. 


A nem reagáló DNS-szerverek kibagyása 

Amikor a DNS-ügyfél elkezd dolgozni, egy úgynevezett ke- 
resési lista lapján teszi mindezt. Ebben a listában a szóba 
jöhető DNS-szerverek prioritási sorrendben szerepelnek. 
Abban a sorrendben, ahogyan beállítjuk a TCP/IP paramé- 
terekben, vagy ahogy például megkapja a gép a DHCP- 
szervertől. Értelemszerűen az elsődleges után jön a másod- 
lagos és így tovább, viszont abban az esetben, ha valame- 
lyik kiszolgáló nem elérhető, akkor ideiglenesen hátrébb so- 
rolódik a listában, automatikusan. 

Mivel a Windows 2000 óta a DNS működése a tartomány, a 
tartományvezérlők, a globális katalógus és még sok-sok to- 
vábbi szerep megtalálása miatt kulcsfontosságú egy tarto- 
mányban, ezért ennek a szerviznek az esetek nagy százalé- 
kában működnie kell. Ha nem így van, azaz leállítjuk vagy le- 
tiltjuk, akkor komoly problémákkal nézünk szembe, hiszen az 
egykori legendás ,... az AD hibák 11096-a a DNS-ből ered" 
mondás százalékértéke mára már kb. vagy 200-nál járhat E. 


License Logging (Licencnaplózás) 

A szerviz rövid neve: LicenseService 

Az alkalmazás neve: Ilssrv.exe 

Függés: — 

Függesztés: — 

Porthasználat: TCP: 135 (csak a replikációhoz) 

Alapértelmezett indítás: letiltva 
Ennek a szerviznek a használata szintén velejárója a Win- 
dows-világnak. Segítségével az eszköz vagy felhasználó 
alapú ügyféllicenceket (CAL - Client Access License) hasz- 
náló beépített komponensek, például az IIS, a Terminálszol- 
gáltatások, a fájl- és nyomtatószolgáltatások vagy a külső 
kiszolgáló alkalmazások, mint az SOL Server vagy az Ex- 
change Server ügyféloldali felhasználásának mértékét állít- 
hatjuk be a törvényes keretek közé. 
A Windows Server 2003-ba beépített License Logging szer- 
viz telephelyenkénti bontásban gyűjti és összegzi a licen- 
cekkel kapcsolatos információkat a telephelyi licencszerve- 
ren. Ez azt jelenti, hogy lehetőség nyílik arra, hogy földrajzi 
vagy szervezeti alapon történjen a licencek beszerzése és 
menedzselése. Ennek a magyarázata elsősorban ott kere- 
sendő, hogy szemmel láthatóan a Microsoft ezen kompo- 
nensét sem a tipikus magyar viszonyokra tervezték O), ha- 
nem a sok ezer gépes, sok telephelyes viszonyok közé. De 
— komolyra fordítva a szót — ez persze semmilyen gondot 
nem okoz a használatában. Ha nem működik ez a szerviz 
(ne felejtsük, el, hogy ugyan a Windows 2000 Servernél 
még automatikusan futott, viszont a Windows 2003 Server 
összes típusánál már alapból tiltva van), akkor az igen, de 
,cCsak" annyit, hogy nem tehetünk eleget a licencek elektro- 
nikus adminisztrálásának. 


Performance Logs and Alerts 
(Teljesítménynaplók és riasztások) 
A szerviz rövid neve: Sysmonlog 
Az alkalmazás neve: Smlogsvc.exe 
Függés: — 
Függesztés: — 
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Porthasználat: TCP: 139 
Alapértelmezett indítás: kézi, leállítva 

Most a kicsit talán nehezen kiismerhető, ám rendkívül hasz- 
nos megoldás háttérszolgáltatása jön, amely jó barátja min- 
den üzemeltetőnek: ez a Teljesítménynaplók és riasztások 
szerviz. Ennek segítségével nyílik lehetőség valamilyen ok- 
ból problémás helyi vagy távoli számítógépek teljesítmény- 
adatainak gyűjtésére. Amikor egy ilyen típusú figyelést haj- 
tunk végre, akkor általában ezt időzítve tesszük, hiszen a 
legtöbb probléma hosszabb távon jön elő. Ez a szerviz ab- 
ban segít, hogy az időzítés szerinti működéskor elindítja a 
naplózást, illetve riasztás(oka)t is kiválthat, ha úgy állítjuk be. 
A szolgáltatás indulása és leállása tehát lehet manuálisan ki- 
váltható (pl. a valós idejű adatgyűjtéskor), de lehet teljesen 
automatikusan abban az időszeletben (mondjuk, naponta x 
percben), ahogyan behangoljuk, például a ,logman" pa- 
ranccsal vagy a Teljesítménynaplók és riasztások konzollal. 
Ha a szerviz fut, és leállítjuk, akkor az adatgyűjtés befejező- 
dik, és a további, általunk generált időzítések szerinti műkö- 
désnek is búcsút mondhatunk. Ezért célszerű az alapbeálli- 
táson hagyni, hiszen ha letelik egy-egy időzítés, vagy nem 
történik esemény, úgyis automatikusan leáll. 


Remote Procedure Call Locator 
(Távoli eljáráshívás lokátor) 

A szerviz rövid neve: RpcLocator 

Az alkalmazás neve: locator.exe 

Függés: Workstation szerviz 

Függesztés: — 

Porthasználat: TCP: 135 

Alapértelmezett indítás: kézi, leállítva (tartományvezérlő- 

kön automatikus) 
Ez a szerviz lehetővé teszi az RPC klienseknek hogy megta- 
lálják a hálózaton lévő RPC kiszolgáló(ka)t, továbbá azt is, 
hogy az RPC névszolgáltatás adatbázisát kezelhessék. A 
szerviz manuális indításúra van állítva az alapértelmezés 
szerint, ha viszont leállítjuk vagy letiltjuk, akkor a kliens felől 
érkező RPC-forgalom nem talál célba, azaz az adott gép 
nem találja meg az illetékes RPC szervert, így az RPC név- 
feloldó adatbázist sem. Ha a szervizt a tartományvezérlőn 
, vágjuk tarkón", akkor nagyobb galibát okozunk, hiszen az 
összes kliens és maga a tartományvezérlő is zavarba jön. 


Simple TCR/IPR Services 
(Egyszerű TCP/IP szolgáltatások) 

A szerviz rövid neve: SimpTcp 

Az alkalmazás neve: tepsvcs.exe 

Függés: AFD Networking Support Environment 

Függesztés: — 

Porthasználat: lásd külön-külön 

Alapértelmezett indítás: automatikus 
Ez a szerviz az olyan utólag, a Windows-összetevők közül 
feltelepíthető extra TCP/IP szolgáltatásokat implementálja, 
mint az Echo, a Discard, Character Generator, Daytime és a 
Ouote of the Day protokollok. 














Cbaracter Generator ( port 49. RFC 863) 

Ez a komponens hasznos hibakereső eszköz a mátrixnyom- 
tatók tesztelésére és hibaelhárítására, mert olyan adatokat 
küld a printerre, ami egy 95 nyomtatható ASCII-karakterből 
álló karakterkészletre épül. 


Daytime (port 43. RFC 867) 

A hét napját, a hónapot, az évet, a pontos időt és az időzóna 
adatait adja vissza. Léteznek olyan alkalmazások, amelyek 
ennek a szolgáltatásnak a kimenetét a rendszeridő változásá- 
nak vagy a rendszeridő és egy másik gép rendszerideje köz- 
ti eltérés hibakeresésére vagy megfigyelésére használhatják. 


Discard (port 9, RFC 863) 

Válasz vagy visszaigazolás nélkül eldobja a portra érkező 
összes üzenetet. Használható TCP/IP tesztüzenetek foga- 
dására és továbbítására, illetve bizonyos esetekben az al- 
kalmazások üzeneteldobási funkcióként is használhatják. 


Ecbo (port 7. RFC 862) 

A kiszolgálóportra érkező összes üzenet adatát visszaküldi. 
Az echo parancs hálózati hibakereső és figyelőeszközként 
hajthat hasznot. 


Ouote of tbe Day (port 47. RFC 865) 

Ez egy abszolút kényelmi szolgáltatás, amely egy idézetet 
küld vissza egy- vagy többsornyi szövegként. Általában a 
levelezőprogramok szignójában szoktuk megjeleníteni eze- 
ket az idézeteket, és a 9ewindiryAáSystem3gADriverstEtoi 
Auotes helyről választódhatnak ki, véletlenszerűen. 
Ezeknek a protokolloknak a használatához tudnunk kell, 
hogy külön-külön nem engedélyezhetők, illetve nem is tiltha- 
tók le, csak egyben (ha eltávolítjuk), ezért ha nincs szükség 
rájuk, ne is telepítsük. Ha viszont feltelepítettük, és elindítot- 
tuk a szervizt, akkor ez az öt protokoll automatikusan enge- 
délyezve lesz a hálózati interfészen. A szerviz leállítása vagy 
tiltása viszont csak ezekre a szolgáltatásokra lesz hatással. 


Windows Media Services 
(VWvindows Média szolgáltatások) 
A szerviz rövid neve: WMServer 
Az alkalmazás neve: WMServer.exe 
Függés: Remote Procedure Call 
Függesztés: — 
Porthasználat: TCP: 1755 (MM9S), 554 (RSTP), 80 (HTTP), 
135 (DCOM, WMI); UDP: 161 (SNMP), 1755 (MMS), 135 
(DCOM, WMI) 
Alapértelmezett indítás: automatikus 
Ez a szerviz sem alapértelmezett, viszont ha feltelepítjük, 
automatikusan indul, és streaming media (adatfolyam-ki- 
szolgáló) szolgáltatást nyújt az IP alapú hálózatok felett. A 
Windows Server 2003-ban lévő WMS a korábbi 4 különálló 
szolgáltatást cseréli le egyre, amely számtalan protokollt is- 
mer (lásd Porthasználat). Ezzel a szolgáltatással például 
hang- és mozgókép-adatfolyamokat kezelhetünk, továbbít- 
hatunk és archiválhatunk az intraneten vagy akár az inter- 
neten keresztül. Ha a szervizt leállítjuk, a streaming media 
szolgáltatás ignorálásán kívül más nem fog történni. 
Cikksorozatunk következő részében elkezdjük a legna- 
gyobb csoport, a LocalSystem fiókkal futó szolgáltatások 
vizsgálatát. 
GÁL TAMÁS 
MCSE, MCSA, MVP 
Stamasatjszki.bu 


A cikkben szereplő URL-ek: 


(11. ftp://ftp.rfc-editororg/in-notes/ rfc230B-txt. 


Két üzleti platform 
rövid kiértékelése 


A LÍINUX És A WINDOWS ÖSSZEHASONLÍTÁSA 


sok vállalat van, amely a nagyszámítógépekről és alUUNIX 


alapú rendszerekről az új Intel alapú megoldásokra való 


átállást fontolgatja, hiszen azok az előbbiek költségeinek 


törtrészéért nyújtanak ugyanolyan, sőt akár nagyobb 


teljesítményt. 


ármilyen könnyű legyen is kiválasztani a hardvert, 

ennél fontosabbá lépett elő az operációs rend- 

szert illető döntés. A platform sokkal több puszta 
operációs rendszernél. Magában foglalja az alkalmazáski- 
szolgálót, a biztonsági szolgáltatásokat, a tranzakciófeldol- 
gozást és az erőforrások címtárát. Ha ezek mind integrálva 
vannak egymással, jóval hatékonyabb üzemeltetést, egy- 
szerűbb felügyeletet és jelentős üzleti hasznot tesznek le- 
hetővé. A platformot illető döntés azért is kulcsfontosságú, 
mert a platform határozza meg, hogy futtatni tudja-e a vál- 
lalat a legkorszerűbb alkalmazásokat, biztonságosan és 
hatékonyan kezelheti-e informatikai erőforrásait, valamint, 
hogy versenyképessége megőrzése érdekében képes-e 
beépíteni rendszerébe a folyamatosan fejlődő új alkalma- 
zásokat. Napjaink gazdasági nehézségei miatt sok vállalat- 
nál szorosabbra fogták az informatikai költségvetést. 
Vannak nagyvállalatok, amelyek hatalmas összegeket ru- 
háztak be nagyszámítógépekbe és UNIX rendszerű számí- 
tógépekbe. A beruházás számítógépes berendezésekben, 
módosított és egyedi alkalmazásokban, valamint támogató 
személyzetben ölt testet. A hardver/szoftvergyártó. által 
esetleg megkövetelt szolgáltatási szerződés díja is jelentős 
összegre rúghat. Ha mindezt figyelembe vesszük, érthető, 
hogy a döntéshozók olyan lehetőségek után kutatnak, 
amelyekkel csökkenthetik az üzemeltetési és a támogatási 
költségeket. Sok vállalat fontolgatja, hogy a drágább vál- 
lalatspecifikus UNIX rendszerekről való áttérést a Linux be- 
vezetésével oldja meg. A Linux sok verziója ingyenes, pon- 
tosabban a telepítő média áráért szerezhető be. Népszerű- 
ségre tett szert bizonyos fejlesztők körében, és a hardver- 
gyártók közül is egyre többen támogatják. 
A helyzet iróniája, hogy hosszú távon sokkal többe kerülhet a 
vállalatnak, ha a Linuxot választja. A számítástechnikai ipar- 
ágat kutató cégek közül egyre több mutatta ki és egyre több 
ügyfél is dokumentálta, hogy a Linuxot választó vállalatok 
többet költenek a további szoftverekre, a munka- és konzu- 
lensi költségekre. Még ennél is fontosabb, hogy jelentős 
többletkockázatot vállal, aki üzletvitelhez nélkülözhetetlen al- 
kalmazásait Linuxon futtatja: a szállító nem vonható felelős- 
ségre, a különféle disztribúciók nem kompatibilisek egymás- 
sal, a Linux üzleti modellje hosszú távon nem gazdaságos. 


A gazdasági kényszer arra készteti a vállalatokat, hogy ke- 
vesebből érjenek el többet, ugyanakkor úgy próbálják 
megoldani az üzleti problémákat, hogy ezzel előnybe ke- 
rülhessenek versenytársaikhoz képest. A Microsoft olyan 
platformot biztosít vásárlói számára, amelynek kiemelt cél- 
ja, hogy minden módosítás nélkül megoldást nyújtson a 
fontos informatikai problémákra, javítsa a termelékenysé- 
get, és egyszerűbbé tegye az informatikai felügyeletet. 


A legfontosabb alkalmazási 

területek kiszolgálása 

A Microsoft úgy véli, hogy a platformot a legfontosabb alkal- 
mazási területeket szem előtt tartva kell elkészíteni. A Win- 
dows termékcsalád tervezésekor olyan megoldás volt a cél, 
amely minimális kiegészítő szoftverekkel vagy azok nélkül 
ad megoldást a gyakori üzleti problémákra. Ez a szemlélet- 
mód gyors bevezetést tesz lehetővé, így vásárlóink gyor- 
sabban juthatnak piacra versenytársaiknál. A platform a kö- 
vetkező alkalmazási helyzetek kezelésére alkalmas: 

m Informatikai infrastruktúra kiépítése: a vállalaton belül 
minden felhasználói fiók, jog és erőforrás felügyeletére 
módot adó egységes, integrált címtárszolgáltatás. 

m Szoftveripari szabványokon alapuló integrált biztonsá- 
gi funkciók, amelyek garantálják a fiókok, az erőforrás- 
ok és az eszközök biztonságát, a vállalat vagyonának 
védelmét biztosító hitelesítési lehetőségek. 

m Beépített kommunikációs lehetőségek, amelyekkel a 
gazdasági szakemberek út közben és otthonról is biz- 
tonságosan érhetik el vállalati e-mail fiókjukat, adatai- 
kat és az üzleti alkalmazásokat. 

m Magas szintű együttműködés a portálalkalmazások- 
kal, az irodai csomagokkal, a webszolgáltatásokkal és 
a folyamatos átvitelű multimédiás lehetőségekkel való 
integrációnak köszönhetően. 

mu Az infomunkások hatékonyságának fokozása, nemzet- 
közi szintű, az ügyfelek/kollégák részvételével zajló 
online értekezletek és információmegosztás révén. 


A termelékenység maximalizálása 


A Windows Server több száz üzleti alkalmazást támogat, 
beépített eszközökkel könnyíti meg az informatikai felügye- 
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letet és a végfelhasználók támogatását, és beépített alkal- 
mazásokkal járul hozzá a termelékenység maximalizálásá- 
hoz. A Windows szabványos kezelőfelületét világszerte 
több millió végfelhasználó és fejlesztő ismeri. Hosszú idő 
óta a Windows jelenti a mércét a használat egyszerűsége, 
a testi fogyatékosoknak nyújtott kisegítő lehetőségek, illet- 
ve az alkalmazások kompatibilitása terén. További funkciói 
közül megemlíthetjük a nagyvállalati használatra kész cím- 
társzolgáltatást, amely a hálózat védelmének és erőforrá- 
sainak (pl. a tárolókiszolgálók) kezeléséhez szükséges. 
Tartalmaz asztali gépek felügyeletére szolgáló eszközöket, 
biztosítja az utazó és a távoli felhasználók munkafeltételeit, 
valós idejű kommunikációs funkciói segítségével pedig vir- 
tuális értekezletek tarthatók, illetve otthonról és a külső te- 
lephelyen végzett munka közben is egyszerűen elérhetők a 
számítógépek és az adatforrások. Az asztali gépeken a 
Windows XP egyszerűbbé teszi a leggyakoribb művelete- 
ket, például a fájlok és a mappák kezelését, az asztalnak 
az egyéni munkastílushoz és ízléshez való hozzáigazítását, 
valamint a futó alkalmazások felügyeletét. A Windows XP- 
nek köszönhetően több felhasználó is dolgozhat ugyan- 
azon a számítógépen, saját jelszóval és saját mappáik biz- 
tonságos elérésével. Kidolgozott fájlvédelmi eljárásai révén 
kiküszöbölhető a rendszerfájlok felülírása, a rendszer-vis- 
szaállítási funkcióval pedig, ha a szükség úgy kívánja, ere- 
deti állapotába állítható vissza a számítógép. A Windows 
2000 Server, a Windows Server 2003 és az Active Directory 
révén a rendszergazdák egyszerűen zárolhatják az asztali 
környezetet, megakadályozva ezzel a felhasználókat ab- 
ban, hogy megváltoztassák a beállításokat, és hogy enge- 
dély nélkül alkalmazásokat telepítsenek, illetve az egész 
vállalatot áttogó módosításokat foganatosíthatnak a bizton- 
sági szabályokban. 


Egyszerű bevezetés és felügyelet 

Az új operációs rendszerek, illesztőprogramok, alkalmazá- 
sok és javítások telepítése a rendszeresen előforduló fel- 
adatok közé tartozik, bármelyik operációs rendszerről le- 
gyen is szó. A Microsoft Systems Management Server 
(SMS) 2003-nak köszönhetően jelentős előrelépés követke- 
zett be a javítások és a programok Windows Server 2003- 
ra történő telepítésében. Az SMS 2003 a Microsoft platform 
teljes körű változás- és konfigurációkezelési megoldása, 
amelynek segítségével a szervezetek gyorsan és költ- 
séghatékonyan biztosíthatják a szükséges szoftvereket és 
frissítéseket a felhasználók számára. Az SMS 2003 az alka- 
Imazásbevezetés módját is továbbfejleszti: megbízhatóan 
és egyszerűen biztosíthatók vele a nélkülözhetetlen üzleti 
és irodai alkalmazások a felhasználók számára, akkor és 
ott, ahol szükségük van rájuk. Segítségével a Microsoft 
Windows környezet biztonsági javításainak kezelése is 
megoldódik: a bevezetés hatékonyságát megkönnyítő 
egyéb elemei mellett célzottan képes eljuttatni a számító- 
gépekre a frissítéseket. 

A Microsoft hatalmas összegeket áldozott és egy külön fej- 
lesztőcsapatot jelölt ki arra, hogy egyszerűbbé tegye a 
Windows 2000 Server és a Windows Server 2003 felügye- 
letét. Számos beépített eszköz és szolgáltatás létezik, ame- 
lyek segítségével kivitelezhető a kiszolgáló távfelügyelete, 
a helpdesk alkalmazott átveheti a problematikus asztali gé- 
pek vezérlését, távolról megoldhatja a felhasználó problé- 


máját. A felhasználók automatikusan tájékoztatást kapnak 
a szoftverfrissítésekről, és ha kérik, automatikusan telepít- 
hetik azokat. A minimális felhasználói felülethez szokott 
UNIX-hívek kedvéért a Microsoft a gyakori felügyeleti mű- 
veletekhez parancssoros kezelőfelületet készített, amely 
be van építve a Windows XP és a Windows Server operáci- 
ós rendszerekbe. 


Jövőkép 

A Microsoft egész története során azok közé a cégek közé 
tartozott, amelyek hatalmas összegeket kockáztatnak a jö- 
vőbeli technológia trendek kapcsán. A szoftvercégek sorá- 
ban 2003-ben a Microsoft vezette a listát: több mind 6 mil- 
liárd dollárt és 35 ezer alkalmazottat szentelt a kutatás-fej- 
lesztési céloknak. 

A döntéshozóknak tisztában kell lenniük a kereskedelmi és 
a nem kereskedelmi szoftverek üzleti és fejlesztési modell- 
je közötti különbségekkel. A Microsoft úgy véli, hogy a nem 
kereskedelmi szoftverek, éppen ebből a jellegükből faka- 
dóan, nem lesznek képesek arra, hogy a Microsofttól meg- 
szokott gyorsaságú innovációval folyamatosan újdonsá- 
gokkal jelenjenek meg a piacon. A Microsoft termékek sike- 
re annak tulajdonítható, hogy létezik egy olyan szervezet, 
amely egyértelmű, előretekintő jövőképpel rendelkezik a 
termék fejlesztéséről, és amely kötelezettséget vállal arra 
az ügyfelekkel szemben, hogy valóra is váltja a jövőképet. 


A birtoklás összköltsége 

A legtöbb vállalat esetében a szoftverek bekerülési költsé- 
ge jóval kisebb, mint a szoftver testreszabásával, beveze- 
tésével, támogatásával és karbantartásával járó költségek. 
Sok informatikai projekt esetében a konzultációs költségek 
és a licencköltségek aránya 8:1 is lehet, tehát minden li- 
cencre fordított forintra nyolc forint konzultációs díj jut. Eh- 
hez párosul még az az elterjedt szemlélet, hogy a projek- 
teknek 12 hónapon belül meg kell térülniük, így egyre fon- 
tosabb, hogy a felhasznált szoftverek módosítás nélkül 
vagy kis módosításokkal futtathatók legyenek. A Microsoft 
azon az állásponton van, hogy egy platform értéke nem 
mérhető pusztán a hagyományos birtoklási összköltséggel 
(TCO-val), ennél is fontosabb figyelembe venni a birtoklás- 
ból származó nagyobb üzleti értéket. 

Vezető elemzők felhívják arra a figyelmet, hogy az operáci- 
ós rendszerek esetében az ár mindössze kis hányadát, 
nem egyszer kevesebb mint 10 százalékát teszi ki a teljes 
birtoklási költségnek (TCO). Számításba kell venni a mun- 
kaerő-felvétellel, kiképzéssel és a konzultációs szolgáltatá- 
sokkal járó költségeket is. Az öt évre vetített birtoklási össz- 
költség kiszámításakor a felügyeletet, az üzemeltetést, az 
alkalmazásfejlesztést, a támogatást és a szoftverfrissítések 
kezelését kell figyelembe venni. 

A jobb összevethetőség érdekében a Microsoft az 
International Data Corporation (IDC) piackutató céget kér- 
te fel, hogy az ügyfelek megkérdezése révén számítsa ki a 
Linux és a Windows vállalati használatának öt évre vetített 
valós költségeit. A vizsgálatban öt tipikus alkalmazási terü- 
let birtoklási összköltségét vetették össze. Ezek a követke- 
zők voltak: webkiszolgálás, biztonság, fájlmegosztás, 
nyomtató-kiszolgálás, hálózati infrastruktúra. A felmérés 
több mint 100 vállalkozásra terjedt ki. Figyelembe vették a 
költségek között a hardver és a szoftver bevezetéséből és 


állásidejéből származó költségeket, a kiszolgálók üzemel- 
tetéséhez szükséges főállású alkalmazottak számát, vala- 
mint a személyi állomány kiképzésének költségeit. Ös- 
szességében a Windows az öt közül négy alkalmazási te- 
rületen (a webkiszolgálás a kivétel) kisebb birtoklási össz- 
költséggel üzemeltethető. A vizsgálat legfontosabb ered- 
ménye az volt, hogy a Linux jóval több munkaköltséget 
vonz. Összességében a Linux háromszor annyi támogatá- 
si dolgozót igényelt, mint a Windows. A Linux esetében 
több fejlesztőre volt szükség a hálózat, a kiszolgálók, az 
asztali gépek, a helpdesk és az alkalmazásfejlesztés ke- 
zeléséhez. 


A Gartner tanulmánya az asztali 
gépek birtoklási összköltségéről 

Az IDC említett vizsgálata a kiszolgálókra összpontosított, 
azonban az asztali gépek esetében is előnyösebb a Win- 
dows a Linuxnál. Ha tökéletesen szeretnénk eljárni, párhu- 
zamosan be kellene mutatnunk olyan vállalatok tapasztala- 
tait, ahol a Linux, és olyanokét, ahol a Windows XP van te- 
lepítve az asztali gépekre. Ez idáig azonban nem tudunk 
olyan vállalatról, amely nagy számban vezetett volna be 
Linuxot az asztali számítógépekre, és hajlandó lett volna 
vizsgálatnak vetni alá magát. A Microsoft azonban felismert 
bizonyos trendeket a Gartner TCO-modelljén alapuló vizs- 
gálatok alapján. 

A Windows 2000 és a Windows XP, valamint az Office XP 
alkotta platform, illetve a Linux és az Open Office (a Star 
Office ingyenes verziója) birtoklási összköltségét összeha- 
sonlító vizsgálat azt mutatta ki, hogy a Microsoft választá- 
sával évente és számítógépenként körülbelül 30 százalé- 
kos megtakarítás érhető el. A megtakarítások jelentős ré- 
sze a Windows XP beépített felügyeleti funkcióból, illetve a 
kevesebb szervizelés miatti leállásból származik. Konkré- 
tan a Linuxra és az Open Office-ra vonatkozóan a követke- 
zőket tartalmazza a jelentés: , Hiányoznak a nagyszámú 
munkaállomás kezelésére alkalmas standard szolgáltatá- 
sok, például a címtár alapú felügyelet (a Novell NDS és a 
Windows 2000 vagy Windows 2003 Active Directory meg- 
felelője). Minthogy a fent említett funkció hiányzik, és mivel 
a rendszerfelügyelet nem a szabványos infrastruktúra ré- 
sze, ezért egymást átfedő funkciójú eszközöket kell meg- 
vásárolni (például a Tivolit), illetve a több különböző kör- 
nyezetből fakadóan később nőnek a felügyeleti költségek." 
(Pohjala, Janne, ,Gartner TCO Study for European City 
Government," 2001. december). 


Alkalmazáskompatibilitási 

problémák 

A nagyvállalatok számítástechnikai környezete jellemzően 
összetett és heterogén. Az informatikai cégek közötti vá- 
lasztási lehetőségek és a megszerezhető érték maximali- 
zálását szolgálja, ha sok olyan független szoftvergyártó és 
rendszerintegrátor vállalat létezik, amely alkalmazásokat 
készít az adott cég platformjára, és támogatja azokat. To- 
vábbi érték származik abból, ha ugyanezek a szoftvergyár- 
tók és rendszerintegrátorok tartósan áldoznak a termékek 
továbbfejlesztésére és támogatásra, meghosszabbítva ez- 
zel ezeknek a platformoknak az élettartamát és gazdasá- 
gosságát. A Gartner 2003 márciusi tanulmányában (, Linux 
Operating System Technology: Prospective") a következő 


áll: ,Bár folyamatban van az alkalmazások Linuxra történő 
átalakítása (,portolása"), arra nézve nincs garancia, hogy 
mindegyik Linux disztribúción futni fognak..." 


Vállalati támogatás 

és szolgáltatások 

Az informatikai platform kiválasztásakor fontos szempont a 
hozzáértő, szakszerű támogatás elérhetősége. Egy jól mű- 
ködő szoftveres ökoszisztéma garantálja, hogy a vállalatok 
igenlő választ kapjanak, amikor azt kérdezik, elérhető lesz- 
e a segítség, ha szükség van rá, vagy hogy hozzájuthat- 
nak-e a versenyképességet biztosító új rendszerek költ- 
séghatékony telepítésére módot adó szolgáltatásokhoz. A 
Microsoft már több mint 20 éve tekinti stratégiai céljának, 
hogy termékei támogatására szoftveres ökoszisztémákat 
építsen ki. Egész iparágak nőttek fel a Microsoft termékei 
körül. További támogatási formák: 

HM LEGNAGYOBB SZÁMÚ FÜGGETLEN SZOFTVERGYÁRTÓ. A 
Microsoft alkalmazásokat támogatja a világon a leg- 
több független szoftvergyártó, akik tanúsítással ren- 
delkező egyéni alkalmazásokat készítenek Windows 
rendszerre, széles körű választékot kínálva a Micro- 
soft ügyfeleinek. 

B ESZKÖZTÁMOGATÁS. A Windows alapkiépítésben több 
mint 19 000 eszközt támogat, és további 41 000 esz- 
köz van tesztelés alatt. 

B TANÚSÍTOTT MEGOLDÁSOK. A Windowshoz több ezer ta- 
núsított hardver-illesztőprogram és szoftver szerezhe- 
tő be külső szoftvergyártóktól, így egyszerűen bővíthe- 
tő a rendszer új hardverekkel és alkalmazásokkal. 

HM  SZOLGÁLTATÁSBÓSÉG. A Microsoft termékeit több mint 
450 ezer MCSE (Microsoft Certified Systems Engineer) 
mérnök támogatja világszerte, ezenfelül 750 ezer for- 
galmazó és partner kínál bőséges választékot. 


Összegzés 

A Linux operációs rendszer ugyan ingyen vagy olcsón be- 
szerezhető, mégis vállalati ügyfelek esetében kisebb a bir- 
toklási összköltsége, ha Windows fut a kiszolgálón és az 
asztali gépeken. A fenti vizsgálatok nem veszik figyelembe 
a Linux és a Windows közötti választásból fakadóan el- 
vesztett lehetőségeket és egyéb kvalitatív tényezőket. A 
nagyvállalati szintű támogatást, az alkalmazások rendelke- 
zésre állását és egyéb kulcsfontosságú összetevőket is fel- 
ölelő stabil ökoszisztéma hiánya azt jelenti, hogy a Linux 
egyelőre nem rendelkezik azokkal a jellemzőkkel, amelyek- 
nek köszönhetően hosszú távon is költséghatékony megol- 
dást jelenthetne a vállalatok számára. 


A cikkben szereplő URL-ek: 


[1]. httpz// www.forrestercom/home/0.60921-1,FF.html 
[2] http:/ /techupdatezdnet.com/ techupdate/ stories/ main/014179.2878232- 
3.00.htmi 


(Cikkünk ,A két üzleti platform kiértékelése: a Linux és a 
Microsoft Windows összehasonlítása" c. tanulmány tömörí- 
tett változata. A teljes tanulmány elolvasható a 
www.microsoft.com/hun/lgetthefacts címen.) 
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Módszertanok, 
módszertanok, 
módszertanok 








A szoftverfejlesztési projektek olyan speciális tulajdon- 


ságokkal rendelkeznek, amelyek miatt sajátos szakmai 


és menedzsmentmódszerekre van szükségünk. 


Ezeket járjuk körül ebben a cikkben, különböző gyakorlati 


szempontok figyelembevételével. 


gy - véleményem szerint -— 

mindenki számára ismerős tör- 

ténettel szeretném kezdeni. 
Képzeljünk el egy fiatal házaspárt, Mr. 
Férjet és Mrs. Feleséget. Szükségünk 
van továbbá Anyucira (ő a férj édes- 
anyja), illetve Anyósra (értelemszerű- 
en a feleség édesanyja). Az apák 
csendes megfigyelői a történetnek. Te- 
gyük fel, hogy egy szép napon a Férj 
arra ébred, hogy sajtlevest szeretne 
enni vasárnap ebédre. A Feleség még 
soha életében nem főzött sajtlevest 
(képzeletbeli párunk még friss házas), 
de lelkesen nekiáll a szakácskönyvek- 
ben keresgélni, és talál is néhány re- 
ceptet. Kiválasztja a legszimpatiku- 
sabbat, bevásárol, és megfőzi élete el- 
ső sajtlevesét. Nagy örömmel tálalja 
délbén az ebédet, ám férje az első fa- 
latok után megrökönyödve tolja el ma- 
gától a tányért, és sértődött hangon 
közli: ez bizony nem sajtleves, Anyuci 
bezzeg milyen finomat tud főzni. 
A Feleség sírva hívja édesanyját, Anyóst, hogy elpanaszol- 
ja, milyen szerencsétlenül sült el próbálkozása. Anyós 
igyekszik őt vigasztalni, és sokéves tapasztalatai alapján 
azt tanácsolja: ,legközelebb száraz fehérbort használj, és 
pár dekányi füstölt sajtot is tegyél bele, az adja majd a za- 
matát, apád is így szereti". 
Következő héten egyik este Feleség korábban megy haza 
munkából, hogy férjét meglepje, természetesen igazi jó 
sajtlevessel. Anyós tanácsait megfogadva, mindenre odafi- 
gyelve készíti el az ételt, és Férjet sikerül is meglepnie. Az 
öröm egészen addig tart, míg Férj meg nem kóstolja. Most 
már nem mer a vasárnapihoz hasonlóan indulatos lenni, 
ezért finoman próbálja meg közölni: bizony ennek a sajtle- 
vesnek még mindig vannak hiányosságai. De sebaj, szom- 
batra úgyis Anyucihoz ígérkeztek ebédre, majd ott meglát- 


Az informatikai 
beszállítók módszer- 
tanai különbözők 
lehetnek, így az általuk w 
képviselt minőségben 
is lehetnek eltérések. / 
Bölcsek Köve azonban 
nem létezik, hiába 

is keressük: 

a sikerre nem létezik 


biztos recept. 


hatja Feleség, mi fán is terem ez a re- 
mek étel. 

A szombat el is érkezik, és Anyuci va- 
lóban remekel: a Férj olyan jóízűen 
eszik, mint már rég, Feleség is érzi, 
hogy a leves nagyon finom, de nem 
tudja eldönteni, mi adja ezt a különle- 
ges zamatot. Ebéd után tehát szorgal- 
masan segít Anyucinak a mosogatás- 
ban, és próbálja kifaggatni, mi a titka. 
Anyuci jóindulatúan elmeséli, hogy a 
sajt szétolvadása után még 5 percig 
kell főzni, utána leszűrni, és a végén 
némi snidlinget szórni a tetejére. Fele- 
ség szorgalmasan megjegyez min- 
! dent, és megígéri Férjének, hogy kö- 
! — vetkező hét végén már nagyon finom 
sajtlevest főz ő is. Hogy biztos legyen 
a siker, hét közben egyik nap ismét ko- 
rábban hazamegy, és anyósa, Anyuci 
utasításai alapján főz egy adag sajtle- 
vest. Az ő megítélése szerint ez tény- 
leg ugyanolyan, mint a szombati volt, 
ezért megnyugszik: hét végén végre 
tényleg sikerül örömet szerezni drága Férjének. 

Elérkezik a vasárnap, Férj már várja az ebédet, bár csend- 
ben némi fenntartásai is vannak azzal kapcsolatban. Fele- 
ség szorgalmasan és lelkesen sürög-forog a konyhában, 
és az eredmény: finom, gőzölgő sajtleves. Pontosabban: a 
leves természetesen finom, és Férj végre meg is eszik egy 
egész tányérral, de még mindig ott a megjegyzés az ebéd 
végén: ez még mindig nem az igazi... 

És mindannyian tudjuk: soha nem is lesz az. 

De vajon miért? 





A sajtleves titka 

Egészen biztosak lehetünk abban, hogy a történet vala- 
mennyi női szereplője remek szakácsnő, imád főzni, és re- 
mek sajtlevest tud készíteni. Mindegyiküknek megvan a sa- 
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ját módszere arra, hogy milyen összetevőkből és hogyan 
kell készíteni, miből mennyi kell, milyen hosszan kell főzni, 
mikor kell leszűrni stb. Kívülálló számára talán nem is feltű- 
nő közöttük a különbség, egy szakértő viszont (a Férj) pilla- 
natok alatt megérzi, ha nem a kedvencét kapja. 

Mi lehet ennek az oka? Miért nem tud a Feleség, az Anyós 
és az Anyuci ugyanolyan levest főzni? Miért nem lesz a Fe- 
leség levese soha ugyanolyan, mint Anyucié? 

A különbségek elég sokrétűek: a nők egyénisége, a kony- 
ha felszereltsége, a tűzhely típusa (gáz, elektromos, kerá- 
mialapos stb.), a rendelkezésre álló fűszerek, azok frisses- 
sége, minősége mind-mind fontos lehet. Összességében 
tehát azt mondhatjuk: a legfőbb befolyásoló tényezők a há- 
ziasszonyok adottságai és a megvalósítás környezete. 


Az , IT-leves?" 

Szép, szép, de hogy kerül a sajtleves egy informatikai cikk 
bevezetőjébe? Akik olvasták ,Az UML és a kosárlabda" cí- 
mű írásom ([1]), azok már gyanakodhatnak: ismét valami- 
lyen hasonlatról van szó. 

A fenti történetet valóban egy informatikai folyamat szem- 
léltetésére szántam: a sajtleves egy tetszőleges szoft- 
verterméket szimbolizál, az asszonyok a szállítók, a Férj 
pedig a megrendelő. Lássuk tehát a fenti történetet ennek 
fényében. 

A Férj az Anyuci által képviselt minőséghez szokott, azt 
szeretné kapni újabb beszállítójától, a Feleségétől is. Ő 
azonban többszörös hátrányban van Anyucihoz képest: 
sem a Férj pontos igényeit nem ismeri, sem Anyuci mód- 
szerét, amellyel a végterméket előállítja. Saját ismeretei, 
képességei és lehetőségei szerint a legjobbra törekszik, a 
kívánt minőséget azonban nem éri el. 

Ekkor segítségért folyamodik, szakértőket von be, akik jól 
bevált módszereket ajánlanak. Ezek a praktikák már bizo- 
nyítottak, hiszen Apuci és Após is boldogok, és imádják fe- 
leségük sajtlevesét. Vagyis a szakértők valós tapasztalata- 
ik alapján adják a tanácsot, amely már bizonyított, amely 
segítségével több sikeres projektet lebonyolítottak már. Te- 
kintve, hogy folyamataik mind tudatosak és jól szervezet- 
tek, pontosan meg tudják adni a pontos receptet, ami alap- 
ján ők - saját körülményeik között — dolgoznak. 

A Feleség nevű beszállító igyekszik mindkettőjük tanácsát 
megfogadni (bár azok különbözőek). A dolog azonban 
mégsem működik: nem sikerül az adott minőséget előállíta- 
ni, nem sikerül megfelelni az elvárásoknak. A bevált mód- 
szerek kudarcot vallanak. A hiba oka ott keresendő, hogy 
az egyes alvállalkozók körülményei mind mások, és ezt a 
különbséget nem szabad figyelmen kívül hagyni. 

Ha az Anyuci gáztűzhelyen főz, ne akarjuk ugyanazokat az 
elkészítési időket tartani kerámialapos főzőlapunkkal. Ha 
kertjében frissen terem a petrezselyem, ne akarjuk a száríi- 
tott ételízesítővel ugyanazt az ízhatást elérni. Ha a tanács- 
adó egy 200 fős cég alkalmazottja, 20 személyes kisválla- 
latunknál ne akarjuk ugyanazt az eredményt elérni. 


Mit tehetünk akkor? 

A megoldás: testreszabás. Ha az Anyuci azt mondja, öt 
percig főzzük, és utána szűrjük le a levest, vegyük figye- 
lembe, hogy neki más a tűzhelye, más sűrűségű szűrője 
van, másmilyen nagyságú darabokra szokta szelni a hagy- 
mát stb. 


Ennek megfelelően lehet, hogy nálunk hét perc főzés kell 
még, és talán nem is kell leszűrnünk a levest, ha a hagyma 
kellően szétfőtt eközben. 

Ha a tanácsadónk azt mondja, hogy ez a projekt négy, jól 
képzett szakemberrel oldható meg, de nekünk tíz embe- 
rünk is van rá, akik viszont kevésbé képzettek, meg kell 
fontolni, hogy ez elég-e a megvalósításhoz, kevés, vagy 
épp még túl sok is. 

Véleményem szerint mindenképp érdemes a ,nagyok", a 
hozzáértők módszereit tanulmányozni, hiszen rengeteg 
alapelem kinyerhető, rengeteget lehet tanulni belőlük, és 
hihetetlen mennyiségű ötlettel gazdagodhatunk. Egyikük- 
nél sem fogjuk megtalálni a bölcsek kövét, de irányt adhat- 
nak arra vonatkozóan, hogy merre érdemes elindulni. 
Ennek megfelelően nem célom tehát egyik módszertan 
mellett sem letenni a voksot. Vannak nagyon jó, átgondolt, 
összeszedett metodikák, ám ezek kreatív gondolatok és 
egyéni ötletek, a probléma és a vállalat átfogó látása nélkül 
semmit nem érnek. 

A következő sorokban ennek megfelelően néhány közis- 
mert és már bizonyított módszertant szeretnék felvázolni, 
mégpedig abból a szemszögből, hogy melyik mit nyújthat 
egy informatikai projekt számára, esetleg némi utalással ar- 
ra, melyiket mikor érdemes alkalmazni. Még egyszer sze- 
retném azonban hangsúlyozni, hogy a , Bölcsek köve" nevű 
módszertan nem létezik, még ha össze is hasonlítunk me- 
todikákat különböző szempontok szerint, mindig az adott 
probléma, az aktuális körülmények, tényezők határozzák 
meg a folyamatok pontos menetét, így az itt leírtak is csak 
egyfajta homályos körvonalai ezeknek a dolgoknak. 


A Microsoft Solutions Framework 
Az MSF a Microsoft módszertana [2], amelynek célja sike- 
res üzleti-informatikai projektek lebonyolítása. Középpont- 
jában a csapat- és a folyamatmodelIi áll, amelyet a projekt- 
vezetésre, a kockázatkezelésre és a készenlétre vonatkozó 
úgynevezett diszciplínák, ajánlások egészítenek ki. 

Az MSF folyamatmodellje a vízesés- és a spirálmodell elő- 
nyeit egyesíti. Megtartja a vízesésmodell mérföldköveit, 
amelyek a projekt egy-egy fontosabb állomását jelképezik. 
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A vízesésmodell esetében úgy kell elképzelni a folyamatot, 
mintha egy valódi vízesésen zúdulnánk lefelé, és egy-egy 
nagyobb kövön fennakadva a projekt egy következő fázi- 
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sába lépnénk át. Ezek a mérföldkövek, amelyek a projekt- 
folyamat egy-egy állomását jelentik: egy fázist zárunk le, a 
termék eljut egy bizonyos állapotba, a szükséges doku- 
mentációk elkészültek stb. 

A sajtleves példájára visszatérve: egy-egy mérföldkő lehet 
a recept tanulmányozása, a bevásárlólista összeállítása, az 
alapanyagok beszerzése, a főzés maga, illetve a tálalás. 
Ebben az esetben a projekt egy egyenes mentén felvázol- 
ható, a mérföldkövek között nincs visszacsatolás sem: ha 
utólag jut eszünkbe, hogy például fehérbor nincs otthon, 
semmi lehetőségünk a korrigálásra, nem mehetünk vissza 
a boltba. A projekt egész egyszerűen meghiúsul, a Férj 
éhen marad. 

Viszonylag hamar felismerték a visszacsatolás szükséges- 
ségét, és megszületett a visszacsatolásos vízesésmodell. 
Ennek lényege az előzőhöz képest, hogy az egyes mér- 
földkövek között már tudunk , viszszafelé" is lépni, azaz ha 
az egyik lépés során kiderül, hogy valamit elhibáztunk, van 
ehetőség azt korrigálni, a korábbi fázisokra vonatkozva is. 
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Ez a modell tehát arra ad lehetőséget, hogy az előző lépés- 
re visszatérjünk, ha ez szükségesnek bizonyul. Vagyis ha 
elfelejtettünk fehérbort vásárolni, lehetőségünk van vissza- 
lépni, felvenni azt bevásárlólistánkra, újra elmenni a boltba 
(az új listával), és pótolni a mulasztást. 

Jól látható, hogy ez a modell már valamivel rugalmasabb, 
ám még mindig rengeteg hiányossága van. 

Ezen hiányosságok, problémák áthidalására jelenthet 
megoldást a spirálmodell alkalmazása, mely a 80-as évek 
második felében született, Barry Boehm munkásságának 
köszönhetően. Alapötlete, hogy a szoftverfejlesztést nem 
egyetlen egyenes mentén képzeli el, mint a vízesésmodelIl, 
hanem spirálvonal formájában: az egyes tengelyek a kü- 
lönböző fázisokat jelentik, a spirál aktuális sugara (origótól 
mért távolsága) a rendszer fejlettségi fokát tükrözi. 

A fejlesztési folyamat egyes lépései mind pluszt adnak a 
majdani termékhez, ezért nő a spirál sugara folyamatosan. 
A körív pedig azért tér vissza újra a kiindulási ponthoz (ter- 
mészetesen a már megnövelt sugárral, tartalommal), mert 
a fejlesztési folyamatot ezúttal nem a projekt lezárásáig, az 
első verzió átadásáig tekintjük, hanem feltételezzük, hogy 
az újabb felhasználói igények, a fejlesztés és a használat 
során felgyülemlett tapasztalatok és a különféle egyéb kö- 
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rülmények szükségessé teszik újabb verziók, újabb válto- 
zatok fejlesztését. Így egy szoftver átadása nem jelenti fel- 
tétlenül a folyamat lezárását, újabb és újabb fejlesztések 
következhetnek. 

Az MSF ezt a két modellt igyekszik egyesíteni: a spirálmo- 
dell inkrementális tulajdonságához hozzáadja a mérföldkö- 
vek által nyújtott előnyöket, vagyis egy-egy fázis végén fel 
kell mérni a helyzetet: mi volt a cél, és abból mit sikerült 
megvalósítani. Ha a további tervekben módosításra van 
szükség, azokat is itt tehetjük meg, illetve a projekt lezárá- 
sára, megszüntetésére is lehetőségünk adódik. 
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Az MSF inkrementális modellje a mérföld- 





kövekkel 


A fenti ábrán jól látható, hogy az MSF folyamatmodellje az 
alábbi fázisokból áll: 


m Elképzelés (Envisioning): 
Korai, kezdetleges tervezés, az üzleti igények körvo- 
nalazása. A fázis végére ismerjük a fő kockázati té- 
nyezőket, és kiválasztásra kerülnek a projekt kulcs- 
fontosságú emberei. 

m Tervezés (Planning): 
Kidolgozzuk a rendszer funkcionális specifikációját, 
megtervezzük a folyamatokat, elkészítjük a költség- 
becslést és a határidőket. Mindezeket úgy kell meg- 
határozni, hogy azok a megrendelőnek és a projekt- 
csapatnak egyaránt elfogadhatók legyenek. 

m Fejlesztés (Developing): 
A fejlesztési fázis nemcsak a klasszikus értelemben 
vett kódolást takarja, hanem a tervek véglegesítését, 
a tesztelési terv és a tesztesetek kidolgozását, vala- 
mint a telepítőkészlet elkészítését is. 
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m  Véglegesítés (Stabilizing) : 
Ebben a fázisban véglegesítjük az adott verziót, hogy 
az szállításra kész legyen: nemcsak magát a szoft- 
vert, hanem a hozzá tartozó dokumentációkat, kiegé- 
szítéseket is lezárjuk. 

m Telepítés (Deploying) : 
Az elkészült, letesztelt programot, a hozzá tartozó kom- 
ponenseket és kiegészítéseket telepítjük a megrendelő 
gépeire, elvégezzük a szükséges beállításokat. A fel- 
használókat betanítjuk a rendszer használatára, hozzá- 
férhetővé tesszük a különböző tanfolyami anyagokat, 
dokumentációkat számukra. Ezzel párhuzamosan az 
üzemeltetést is felkészítjük a rendszer átvételére. 


Az MSF másik nagy (véleményem szerint a nagyobbik) ütő- 
kártyája a csapatmodell: alapkoncepciója ugyanis az, 
hogy hat, egymással egyenrangú szerepkört képzel el. 
Ezen szerepkörök mind azonos súllyal vesznek részt a 
megvalósításban, és azért fontos a megkülönböztetésük, 
mert érdekeik gyakran egymásnak ellentmondásosak is le- 
hetnek. Természetesen nem feltétlenül szükséges, hogy a 
hat szerepkört hat ember képviselje, kisebb csapatoknál 
lehetőség van bizonyos összevonásokra is, ám ekkor is fi- 
gyelembe kell vennünk a lehetséges konfliktusokat. A dön- 
tések ennek megfelelően közös megegyezés alapján, kon- 
szenzussal (tehát nem egyszerű többséggel!) születnek. 
Az MSF csapatmodellje az alábbi szerepköröket tartal- 
mazza: 
m Termékmenedzsment: 
feladata az ügyfél érdekeinek képviselete, ő az úgy- 
nevezett , szóvivő", a megrendelő kezelője, 
ma Programmenedzsment: 
arról gondoskodik, hogy a projekt időre befejeződjön 
ma Fejlesztés: 
tervezi és készíti (, kódolja") a szoftvert, 
m User experience: 
a felhasználó szóvivője, a felhasználói felület (UI) ter- 
vezője, 
m Release menedzsment: 
a termék szállításáért felelős. 


Mint már említettem, e szerepkörök a projekt során mind 
egyenrangúak. Munkájuk során mindig szem előtt kell tar- 
tani, hogy a sikeres projekt legfontosabb ismertetőjegye az 
elégedett ügyfél, így mindig arra törekedjünk, hogy őt a le- 
hető legjobban vonjuk be a munkába. Vegyen részt a terve- 
zésben, a kockázatok azonosításában, lássa a készülő fel- 
használói felületet stb. 

Munkánk eredményére, bármi legyen is az (szoftver, szol- 
gáltatás vagy bármi más), mindig termékként tekintsünk, 
és annak minél jobb minőségéért a lehető legtöbbet tegye 
meg valamennyi csapattag. Ha mindenki minőségi munkát 
végez, a termék minősége is jobb lesz (optimális esetben). 
Mindemellett legyünk nyitottak az új dolgokra, a problémák 
újszerű megoldásaira, legyen meg bennünk a hajlandóság 
és az igény a tanulásra. Az informatikai szakterületen nem 
kell hangsúlyozni a naprakész tudás fontosságát, de saj- 
nos még mindig nagyon sokan vannak, akik nem helyez- 
nek erre kellően nagy hangsúlyt. 

Mindezek eléréséhez nagyon fontos a csapat megfelelő 
motiválása: sajnos a jobb minőség több munkával jár, ezt 


pedig (főleg eleinte) általában nem fogadják kitörő lelkese- 
déssel munkatársaink. A motivált emberek, csapatok jobb 
minőség előállítására képesek, hiszen van , miért" dolgoz- 
niuk, a sajátjuknak érzik a problémát. A motiváció elsődle- 
ges formája napjainkban a pénz, azonban rengeteg egyéb 
lehetőségünk is van: közös kirándulások, vacsorák, sport- 
események stb. Az emberek általában szeretik, ha , törőd- 
nek" velük, és elégedettségüket nem csupán bankszámlá- 
juk vastagságában mérik. 


Az MSF fenti két modellje (folyamat- és csapatmodell) az 
őket kiegészítő ajánlásokkal egy jó keretet adhat munkánk- 
nak. Vigyázzunk azonban, hiszen mindez csupán egy 
nyomvonalat, egy ösvényt határoz meg számunkra, amely- 
ről letérhetünk, választhatunk másik útvonalat, majd ha úgy 
gondoljuk, visszatérhetünk az MSF-hez. Tipikus ilyen ,leté- 
rés" szokott lenni az MSF folyamatmodelljének RUP-pal 
vagy más módszertannal történő kiegészítése, esetleg he- 
lyettesítése. 


A Rational Unified Process 

A Rational Software fejlesztési módszertana [3] némileg el- 
tér az MSF-től. Elsősorban a folyamatra koncentrál, a szoft- 
ver életciklusát az üzleti modellezéstől egészen a telepíté- 
sig felöleli. Használati eset vezérelt, iteratív és inkrementá- 
lis fejlesztési módszertan. Mit is jelent ez? 

Az inkrementális szó jelentését már láthattunk a spirálmo- 
dell bemutatásakor: nem egyszerre akarjuk kifejleszteni az 
egész rendszert, nem szánunk éveket a teljes megvalósí- 
tásra, miközben a megrendelő elveszíti minden türelmét; 
ehelyett egyre bővülő funkcionalítással mindig átadható ál- 
lapotban lesz a rendszerünk. Nem az a cél tehát, hogy min- 
den funkciót egyszerre fejlesszünk, hanem az, hogy egy- 
egy újabb funkciócsoporttal gazdagodjon folyamatosan a 
szoftverünk. 

Az iteratív megközelítés azt jelenti, hogy a fejlesztési fázi- 
sok több iterációból állnak össze. Minden fázisban külön- 
böző munkafolyamatokat (workflow) végzünk, amelyek ará- 
nyát az alábbi ábra szemlélteti: 


Disciplines 
Business Modeling 
Reguirements 
Analysis 8. Design 
Implementation 


Test 
Deployment 


Configuration 
8. Change Mgmt 
Project Management 
Environment 


Iterations 





A RUP fázisai, munkafolyamatai 
és az iterációk 


A RUP munkafolyamatai két nagy csoportba sorolhatók: 
4. műszaki, szakmai folyama tok: 


m üzleti modellezés, 
u követelményelemzés, 
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elemzés és tervezés, 
implementáció, 
tesztelés, 

telepítés; 


2. támogató üzleti folyamatok: 
mM konfiguráció- és változáskezelés, 
u projektmenedzsmernt, 
mu környezet rkialakítása. 


Értelemszerűen a műszaki folyamatok 
a megvalósításhoz kapcsolódó konk- 
rét informatikai lépéseket takarják, míg 
a támogató funkciók a járulékos, nem 
szorosan szakmai, de legalább annyi- 
ra fontos teendőket. 

A fenti ábra nem szemlélteti ugyan, de 
RUP is a spirálmodell alapján építi fel 
modelljét, ami hasonló fejlődést tesz 
lehetővé, mint az MSF esetében. Attól 
való eltérést találhatunk viszont, ha a 
csapatmodellt, a szerepköröket ves- 
szük szemügyre. A RUP ugyanis nem 
hangsúlyozza külön ezek jelentősé- 
gét: kitér ugyan arra, hogy kik lehetnek 
az egyes folyamatok résztvevői, de 
fontosságukat és a közöttük lévő kap- 
csolatokat, rendezettséget nem hang- 
súlyozza. 

Ugyancsak eltérés, hogy a RUP a fo- 
lIyamatmodellbe ,belemosva" tartal- 
mazza azokat a támogató, kiegészítő 
teendőket, amelyeket az MSF külön 
ajánlásokként tárgyal. Ugyanakkor a 
Rational Software nagy hangsúlyt fek- 
tet a folyamatokat támogató szoftverek 
fejlesztésére is, amelyek most már gyakorlatilag a teljes 
életciklust lefedik. 


Egyéb módszertanok 

Természetesen rengeteg módszertan létezik, amelyet kü- 
lönböző cégek, fejlesztők dolgoztak ki munkájuk megkön- 
nyítése érdekében. Ezek közül egyet emelnék ki, amely az 
Extreme Programming (XP [4]. 

Az XP a 90-es évek elején született, fő célja az ügyfél-elé- 
gedettség. Arra ösztönzi a fejlesztőket, hogy a megrende- 
lői igények változásait mindig rugalmasan kezeljék, bármi- 
lyen későn jelentkezzenek is azok. Természetesen erős, ös- 
szetartó, hatékony csapatra épít, és itt is kikötés, hogy a fo- 
lyamatban részt vevő valamennyi ember elsődleges fel- 
adata minőségi szoftver szállítása. Ennek érdekében négy 
tényező kap különös hangsúlyt: a kommunikáció, az egy- 
szerűség, a visszacsatolás és a bátorság. Az ügyfél elége- 
dettségének érdekében nagyon fontos, hogy folyamatosan 
bevonjuk őt a munkába, visszajelzéseivel azonnal reagál- 
jon már az első pillanattól kezdve. Így valóban az ő igényei 
és elvárásai szerint dolgozhatunk, amelyek akár változhat- 
nak is az idő előrehaladtával: akár a technológia fejlődése 
miatt, akár egyéb, külső körülmények hatására, sőt az is el- 
képzelhető, hogy a rendszer fejlődésével ráébred arra, 
hogy ő maga sem volt tisztában pontos igényeivel. Mind- 


A szoftverek fejlesz- 
tése során olyan 
speciális termék 
előállítása a cél, 
amelyet nem lehet 
párhuzamba állítani 

az autógyártással, 

a könyvkiadással 

vagy a fuvarozással. 

A szoftver olyan 
szellemi termék, amely 
sajátos tulajdonsá- m 


gokkal rendelkezik. 


ezekre fel kell készülni, bármilyen módszertan alapján dol- 

gozunk is. Az XP erre a tényezőre helyezi a hangsúlyt, és 

ennek érdekében sorakoztatja fel ajánlásait. 

Az XP-t talán egy óriási kirakójátékhoz (puzzle) lehetne ha- 

sonlítani: rengeteg apró elemből áll, amelyek önmagukban 

semmit nem jelentenek, együttesen azonban egy gyönyörű 
képet mutatnak. Sokaknak az XP-ről a párban történő prog- 

ramozás jut eszükbe, vagy az, hogy a 

megrendelőnek folyamatosan benn 

kell ülnie a fejlesztők között. Ezek 
azonban csak egy-egy szeletei a való- 

di XP-nek, amely ennél egy sokkal ös- 

szetettebb, finomabb módszertan. 

A fejlesztési projektek során joggal 

merülhet fel a kérdés: miért van szük- 

ség kifejezetten IT-módszertanokra, 
miért nem jók nekünk a klasszikus, ki- 
forrott projektmenedzsment-módszer- 
tanok? Hiszen azok , univerzálisak", ál- 
talánosan elterjedtek. Ha mindenkinek 
jók, nekünk miért nem? A válasz na- 
gyon egyszerű: pontosan ez az általá- 
nosság az, ami miatt ezek a metodikák 
nem alkalmazhatók szoftverfejlesztés 
esetén: itt ugyanis olyan speciális ter- 
mék előállítása a cél, amelyet nem iga- 
zán lehet párhuzamba állítani az autó- 

gyártással, a könyvkiadással vagy a 

fuvarozással. A szoftver egy olyan 

szellemi termék, amely sajátos tulaj- 
donságokkal rendelkezik: 

a termék sokszorosítása nem 

okoz problémát, ellentétben azokkal a 

termékfejlesztésekkel, ahol az 

utángyártás folyamata is alapos terve- 
zést, odafigyelést igényel, 

m a hordozó, kézzel fogható médium értéke elenyésző 
a szoftver szellemi értékéhez képest, 

m soha nincs két egyforma , gyártási" folyamat: a szoft- 
verek mindig különbözőek, más körülmények között 
készülnek, így a fejlesztés mindig egyedi, sajátos tu- 
lajdonságokkal rendelkezik, 

m a szoftverek jelentős része nem tömeges igényt 
igyekszik kielégíteni, hanem egyedi megrendelés 
alapján készül. 


Mindez indokolttá teszi, hogy a speciális tulajdonságoknak 
megfelelően speciális módszertanokban gondolkozzunk. 


Speciális problémák 

A módszertanok mellett számos olyan probléma merülhet 
fel a fejlesztés során, amelyre korábban már dolgoztak ki 
megoldási javaslatokat. Rengeteg ilyen speciális ajánlás 
van, ezek közül csak néhányat ragadnék ki példaként. 
Gondolom, a , Design Pattern" (DP) kifejezés mindenki szá- 
mára ismerős. A DP-k gyakran előforduló problémákat ír- 
nak le, azok környezetével együtt. Olyan működő megoldá- 
si javaslatokat nyújtanak, amelyek gyakorlati tapasztalatok 
alapján hatékony választ adnak az adott kérdésre. Elsősor- 
ban a szoftver tervezésénél használatosak, amikor a felme- 
rülő megrendelői problémákra keressük a megoldást. 


Olyan sémák ezek, amelyek csak tanulással, olvasással, 
tapasztalatszerzéssel bővíthetők. Célszerű egy saját vagy 
céges DP-gyűjteményt létrehozni, amelyben hatékonyan 
kereshetünk, és amelyet folyamatosan karbantartva egyfaj- 
ta tudástárként használhatunk. Természetesen bizonyos 
idő után már a fejünkben is összeáll egy kép a leggyakrab- 
ban használt tervezési mintákról, ám Ézs 
ezek egyre bővülnek, és számuk is ro- 
hamosan nő. 

Kérdés lehet, hogy milyen követelmé- 
nyeket állítunk rendszerünkkel szem- 
ben: hatékonyság, rendelkezésre ál- 
lás, tanulhatóság stb. mind fontos le- 
het, ám gyakran kompromisszumokra 
kényszerülünk. Érdemes végiggon- 
dolni, mi az, ami igazán fontos, és mik 
azok a tulajdonságok, amelyekből 
engedni tudunk: egy telefonközpont 
1/10 000 hibaaránya tűrhető, sőt jónak 
mondható, ám ugyanez például egy 
orvosi műszernél nem megengedhe- 
tő. Egy bankkártya-leolvasó egység- 
nél 5-10 másodpercet türelmesen ki- 
vár az ember, ám egy erőmű vezérlő- 
szerkezeténél ekkora késleltetés vég- 
zetes lehet. 

A dokumentáció fontosságát rengete- 
gen hangsúlyozzák, mások egyáltalán 
nem tartják lényegesnek, sőt kifejezet- 
ten felesleges időtöltésnek gondolják. 
Véleményem szerint az egészséges 
megközelítés valahol félúton van: meg 
kell találni azt az egészséges arányt, 
ahol még nem esünk túlzásokba, vi- 
szont minden a kellő mértékben le van 
dokumentálva, a későbbiekben érthe- 
tő, hozzáférhető iratokat találunk róla. 
Mindez nemcsak a kódokra, komponensekre vonatkozik, 
hanem az egyes tevékenységekre is: érdemes rögzíteni a 
folyamatok pontos menetét, illetve az egyes döntések hátte- 
rét is, mit miért csinálunk, milyen háttere, körülményei van- 
nak a határozatoknak stb. Mindez a szakmai és az üzleti fo- 
lyamatokra egyaránt érvényes. Célszerű kialakítani egy kö- 
zös vállalati dokumentumtárat, ahol strukturáltan mindenki 
elhelyezheti saját iratait. Szerkezetének, felépítésének kidol- 
gozása alapos megfontolást igényel, hiszen egyrészt szük- 
ség lehet projektenkénti nézetekre is, másfelől a vállalat fel- 
építését, hierarchiáját tükröző szerkezetre is. Természetesen 
a megfelelő jogosultságkezelést is meg kell valósítani, hogy 
mindenki csak azokhoz a könyvtárakhoz/dokumentumokhoz 
férhessen hozzá, amelyek valóban kellenek munkájához. 
Szintén a folyamatok támogatásához lehet hasznos különfé- 
le belső levelezőlisták létrehozása. Kis cégeknél (de akár 
nagyobbaknál is) gyakran megfigyelhető, hogy az egyes 
csapattagok úgy tartják egymással a kapcsolatot, hogy az 
e-mail címzettjei közé mindig felveszik a megfelelő szemé- 
lyeket. 8-10 név is szerepel a listában esetenként. Sajnos 
ennek a megoldásnak több buktatója is lehet. Egyrészt 
akarva-akaratlanul is előfordulhatnak olyan szituációk, ami- 
kor kifelejtünk valakit a címzettek közül, mert például újon- 
nan érkezett a céghez, most kapcsolódott be a projektbe 


A dokumentációk 
készítésénél meg 

kell találnunk azt 

az egészséges 

arányt, ahol még 

nem esünk túlzásokba, 
viszont minden ! 
a kellő mértékben 
dokumentált. 
Mindez nemcsak 

a kódokra, hanem 
az egyes tevékeny- 
ségekre, folyama- 


tokra is érvényes. 


stb. Ugyanígy olyannak is elküldhetjük véletlenül, aki nem 
érintett, sőt rossz helyre is címezhetjük. Ez utóbbira lehet 
példa két azonos vagy hasonló nevű kolléga: annak idején 
egyik munkahelyemen agnes .molnar felhasználói név- 
vel szerepeltem, amikor érkezett egy agi . molnar, termé- 
szetesen egy egészen más részlegre, az enyémtől teljesen 
—.. —— eltérő beosztásba. Nagyon gyorsan rá 
kellett szoknunk arra az algoritmusra, 
hogy ha egy e-mail tartalmát nem ér- 
tettük, gondolkodás nélkül küldjük to- 
vább a másiknak, illetve telefonon is 
már rutinból irányítottuk egymáshoz a 
hívásokat. Ugyanilyen problémát okoz- 
! — hat, ha például amolnar az azonosí- 
tóm, és a következő embernek, aki ezt 
kapná, már két betűt vesznek figye- 
lembe a keresztnevéből stb. Így akar- 
va-akaratlanul is hozzám érkeznek az 
akmolnar, andmolnar stb. címre 
szánt levelek, annak ellenére, hogy 
sem Ákos, sem pedig Andrea nem va- 
gyok. Egy projekt keretein belül mind- 
ezen problémákat jól karbantarthatjuk 
! . naprakész levelezőlistákkal, amelyek 
! — beszédes nevet viselnek, és tagjai 
mindig az aktuálisan érintett csapatta- 
gok. Ráadásul a listák archívuma is 
mindig hozzáférhető, így az sem okoz- 
hat problémát, ha valaki véletlenül töröl 
egy levelet lokálisan vagy megtelt pos- 
taládája miatt. A levelezőlisták mellett 
létrehozhatunk céges blogokat is, aho- 
vá az aktuális tudásanyagot töltjük fo- 
lyamatosan, a munkatársak aktív rész- 
vételével. 
Tovább segíthetik munkánkat a külön- 
böző verziókezelő- és tesztrendsze- 
rek, a követelmények felmérését támogató űrlapok, alkal- 
mazások is. Célszerű lehet a projektek lezárásakor időt és 
energiát szánni az értékelésre és a leszűrt tapasztalatok 
dokumentálására is, hiszen így rengeteg tapasztalatot ad- 
hatunk át más csapatoknak, illetve a jövőbeli projektek szá- 
mára. 
Összességében elmondható tehát, hogy a különféle mód- 
szertanok sokat segíthetnek munkánkban. Ha jól alkalmaz- 
zuk őket, és céljaink elérése érdekében a megfelelő kom- 
ponensekkel egészítjük ki, jó úton haladunk a siker felé. Ah- 
hoz azonban, hogy eldönthessük, melyik módszertant 
akarjuk alapként beépíteni folyamatainkba, alapos, gondos 
előkészítésre és tapasztalt, képzett szakemberekre van 
szükség. 





MOLNÁR AGNES 
molnar.agnesecleware.bu 


[1] http:/ / aghy.uw.hu 

[2] http:// www.microsoft.com/msf 

[3] http:/ / wwibm.com/ software, rational / 
[4] http:/ / www.extremeprogramming.org 
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Üzletiintelligencia- 


szoftverek 


MS SOL 2000 REPORTING SERVICES III. RÉSZ 





Az üzleti intelligencia minden vállalat életében nélkülöz- 








hetetlen, segítségével megalapozott döntéseket 


hozhatunk, amelyek sikeressé tesznek minket a piacon. 


Az üzleti intelligencia nem feltétlenül igényel egy teljes 


OLAP-ot vagy adatbányászatot, mint amilyenek az SOL 


Server Analysis Services-re épülő megoldások, 


de minden üzletiintelligencia-megoldásnak van egy 


közös eleme: a Jelentések (Report-ok)]. 


Reporting Services-t (továbbiakban AS) bemutató 

sorozatunk harmadik, és egyben befejező részé- 

hez értünk. A korábbi részekben megismerked- 
tünk az architektúrával, a szerver felépítésével, a jelentés- 
készítés életciklusával, a Visual Studio .NET 2003 által tá- 
mogatott kimutatáskészítéssel, a Report Manager alkalma- 
zással és a jelentéselérési módokkal. Ebben az utolsó rész- 
ben főként azzal foglalkozunk, hogy miként lehet a koráb- 
ban ismertetett lehetőségeket testre szabni, kiterjeszteni. 
Mindezek mellett szót ejtünk kész kimutatásaink telepítési 
kérdéseiről. Még mielőtt belekezdenénk, aki már rendelke- 
zik telepített RS környezettel, mindenképpen frissítse a 
hozzá tartozó Books Online (továbbiakban RSBOL) súgót 
innen: [1], mert rengeteg változás van benne az eredetileg 
települt példányhoz képest (persze az MSDN Library onli- 
ne oldalain is elérhetjük a legfrissebb állapotot). 


Az RS.EXE segédeszköz 

Ahogyan az SOL Server 2000 eléréshez is megszületett 
egy olyan parancssori eszköz, amelynek paraméterében 
megadott kapcsolódási információk mellett (szervernév, 
felhasználónév, jelszó stb.) automatikusan bejutottunk egy 
olyan környezetbe, ahol közvetlenül kommunikálhattunk a 
szerverrel (ez volt az OSOL.EXE), úgy a Reporting Server- 
hez is készült egy ilyen eszköz. A neve AS.EXE, és úgyszin- 
tén a Wrogram FilesWicrosoft SOL Serven8OolWToolst8inny 
könyvtárban található (alapértelmezésben az SOL Server 
2000 telepítő betette a PATH útvonalai közé), amennyiben a 
AS telepítésekor az adminisztrációs eszközök telepítését is 
kiválasztottuk. Ez az eszköz (ellentétben az OSOL.EXE-vel) 
csak scriptfuttatásra használható, amelyet bemeneti állo- 
mányként adunk meg a paraméterek között. A script-fájl 
unicode vagy UTF-8-as kódolású szöveges állomány (kizá- 
rólag .rss kiterjesztéssel), és a nyelve csakis Visual Basic 
.NET. A segítségével adminisztrálhatunk egy adott Report 





Server-t, adatbázist másolhatunk egyik szerverről a másik- 
ra, publikálhatunk új kimutatásokat a szerverbe stb. A futta- 
tásához helyi adminisztrátori jogosultság kell. A paraméte- 
rezése: 


rs (-?) [-i input file) [-s serverURL] 
(-u username) (-p password) (-1 time out) 
(-b ) (-v globalvars) (-t ) 


Mint látható a paraméternevekben, kívülről adhatunk érté- 
ket a script-ben szereplő globális változóinknak: 


rs -i Script.rss -s http://servername/reportser- 
ver -v report-"Company Sales" 


Érdemes megnézni a példakimutatások szerverbe való 
publikálásához használható ISampleslScriptsV  Publish 
SampleReports.rss állományt is. Célszerű megkeresni a 
script-ben a PublishReport() függvényhívásokat, mert két 
példakimutatás hiányzik a végéről (,Foodmart Sales", 
,Froduct Line Sales"), amit a teljesség kedvéért nem árt ki- 
pótolni tanulás gyanánt (persze ez utóbbi két kimutatás 
működéséhez egy telepített OLAP FoodMart2000-es pél- 
daadatbázisa is szükséges). A script kötelező belépési 
pontja a Main) eljárás: 


Public Sub Main() 
" Itt kezdődhet a saját kódunk 
End Sub 


Persze újabb saját eljárásokat és modulszintű változókat is 
alkalmazhatunk benne. A script automatikusan olyan kör- 
nyezetben fut, ahol már létezik a kapcsolat a Report 
Server-rel (létezik már egy web proxy osztály), amelynek 
példányára egy ,rs" objektumváltozón keresztül rögtön hi- 
vatkozhatunk is (pl. rs.Credentials, rs.CreateFolder(), 
rs. CreateDataSourcef(), rs. CreateReport()). Névtereket nem 
szabad importálni, a következő névterek már eleve létez- 
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nek: System.Web.Services, System.Web.Services. Proto- 
cols, System.XmlI, System.IO. Részletesebb információkról, 
további parancssori eszközökről (mint az rsconfig, 
rskeymgmt, rsactivate) a RSBOL-ban olvashatunk: [2]. 


Kimutatások telepítése 

Felmerülhet mindenkiben a kérdés, hogyan jut el a fejlesz- 
tett kimutatásunk az ügyfél adatbázisába. Az első megol- 
dás a fent említett script megírása oly módon, hogy kívülről 
vegyen át dinamikus paramétereket (mint pl. a kimutatás 
publikált neve, forrás és célútvonala stb.). Ezzel a megol- 
dással elkészíthető egyetlen jól megírt (hibákat kezelő) 
script, majd egy batch-fájlból vagy akár egy verziócserélő 
kliensalkalmazás commandshell-jéből dinamikusan felpa- 
raméterezhetjük az RS.EXE-t. Az RS.EXE futása alatt kelet- 
kezett hibák automatikusan a konzolon jelennek meg, a ,-f 
paraméter megadása mellett a pontos kódja is megjelenik, 
amit ha feldolgozunk, detektálható a hiba oka (az output-ot 
batch esetén fájlba irányítjuk, vagy egy .NET-es kliensen 
keresztül indított AS.EXE futtatása esetén akár a 
Process.StandardError, Process.StandardOtput is felhasz- 
nálható a konzolra küldött válasz visszaolvasására). A pon- 
tos hibakódok itt találhatók: [3]. 

További megoldás lehet a korábban megismert Report Ma- 
nager ASPNET-es alkalmazás, amelyben van lehetőség a 
felhasználói felületen a fájlrendszerből RDL kiterjesztésű ki- 
mutatásállományok publikálására. Persze ez nem automa- 
tizálható, inkább egyszeri, ad hoc beavatkozásként jöhet 
szóba. Egy újabb megoldásként mi magunk írhatunk egy 
kis keretrendszert, amely képes valahol a fájlrendszerben 
tárolt RDL állományok automatikus publikálására (a RS 
webszolgáltatás webmetódusain keresztül). 


Kiterjesztési lehetőségek 
A korábbi részek olvasói számára ismerős lehet a követke- 
ző AS platformról szóló ábra. 
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A Reporting Services platform 


Az ábrából is kivehető, hogy a jelzett szolgáltatások egye- 
di megvalósításokkal is kiterjeszthetőek (erre utal az ábrán 
szereplő megannyi , Custom" szócska), azaz a AS így lett 
tervezve, hogy képes legyen az általunk elkészített . VET-es 
kód felhasználásával bizonyos működést kiterjeszteni, és 
ezáltal biztosítani azt az üzleti logikát, amire nekünk éppen 
szükségünk van az adott alkalmazás esetében. A követke- 
ző komponensek (az ábrából is kiolvasható) esetében van 
lehetőségünk a beépített funkciók kiterjesztésére: 


m Adatfeldolgozás (Data Processing): a beépített SOL 
Server, OLEDB, Oracle és ODBC adatforrás-támoga- 
tásokat terjeszthetjük ki újabbakkal, beolvashatunk 
egy saját egyedi adatforrásból adatokat, egyedileg 
rendezhetjük stb. 

m Kézbesítés (Delivery): a meglévő e-mail- és fájl- 
megosztáson felül kiterjeszthetjük például faxra, 
pager-re vagy éppen nyomtatóra történő kézbesítési 
lehetőségekre. 

m Megjelenítés (Rendering): az eddigi HTML, XML, Ex- 
cel, CSV. Image, PDF, megjelenített formátumokon 
felül készíthetünk újabbakat. 

m Biztonság (Security) szolgáltatások kiterjesztése ese- 
tén a támogatott Windows és Passport alapú bizton- 
ságot kiterjeszthetjük például egyéni űrlap alapú 
(form-based) autentikációt támogató biztonságra. 


A fenti négy komponens közül háromra már készült Micro- 
soft-ajánlás, pontosabban példakód. Ebből két példát 
együtt kapunk a RS telepítésével (SampleslExtensionst 
könyvtár), az egyik az FsiDataExtension, a másik pedig a 
PrinterDeliverySample. A harmadik példa letölthető innen 
[4], és telepítés után a fenti kettő mellé települ, a neve: 
FormsAuthenticationSample. Ahogy az elnevezésekből kö- 
vetkeztethetünk rá, egy kiterjesztés maradt ki: a megjelení- 
tés (rendering) kiterjesztése. Ez utóbbi a legkomplexebb 
és a legbonyolultabb, hiszen a jelentésfájl (RDL) minden 
XML-elemének kombinációját támogatnia kell, a Report 
Object Model oly hatalmas, de a bátrabbak nekieshetnek 
az IRenderingExtension interfész saját implementálásának. 
Készül hozzá a későbbiekben egy dokumentáció is, de 
még várni kell egy picit rá, amíg teljes lesz. Addig is azt 
ajánlják a AS fejlesztői, hogy mielőtt valaki belevág, fontol- 
ja meg a következő alternatívákat: 
m Egy meglévő megjelenítési kiterjesztés módosítása. 
m A megjelenítés módosítása egy létező kiterjesztéssel 
az eszközinformáció-beállítások (device information 
settings) megadásával. 
m Az egyedi formázást és megjelenítést biztosító XML 
megjelenítési kiterjesztés kombinálása XSL transzfor- 
mációval (XSLT). 


A meglévő adatforrások 
kiterjesztése 

Nézzük meg az FsiDataExtension példaalkalmazáson ke- 
resztül, hogy miként tudunk újabb adatforrásokat létrehoz- 
ni a AS számára, azaz miként is terjeszthető ki az adatfel- 
dolgozás. Legyen az adatforrás egy tetszőleges útvonalon 
található mappák és állományok adatai (a mappák és fájlok 
nevei, létrehozási dátumuk, méretük, típusuk). Minden AS 
kiterjesztés előre definiált interfészeken keresztül történhet. 
Az interfészek eljárások, függvények implementációját 
kényszeríti ki a saját kódunkban. Így az AS keretrendszer — 
az előre definiált interfészeket is implementáló saját osztá- 
lyunkat felhasználva - biztos lehet abban, hogy rendelke- 
zésre állnak egy-egy feladat végrehajtásához szükséges 
függvények, eljárások. 

A Microsoft.ReportingServices. DataProcessing névtérben 
a következő interfészeket találjuk: /DataParameter, IData 
ParameterCollection, IDataReader, IDataReaderExtension, 
IDbCommana, IDDCommandAnalysis, IDbConnection, IDb 











ConnectionExtension, . IDbTransaction, . IDbTransaction 
Extension. Nézzük meg annak a legfőbb részeit, miként 
implementálhatjuk ezt a saját adatforrást az interfészleírá- 
sok tükrében. A következő kódban az [DataReader inter- 
fész az adatok beolvasását végzi el az FsiDataReader osz- 
tályunkban. A következő kódok csak részletek, nem imple- 
mentálnak teljeskörűen egy-egy interfészt, csak a lényeges 
eljárásokat emelik ki. 


public class FsiDataReader: IDataReader ( 
private FsiConnection m connection — null; 
internal DirectoryInfo m dir; 
internal FileSysteminfo[] m fsi; 
internal int m curRow; 
internal IEnumerator m ie; 
internal String[] m names - ("Név", "Méret", 
"Típus", "Létrehozás dátuma"); 
internal Type[(] m types -— (typeof(String) , 
typeof(1ong) , typeof(String) , 
typeof(DateTime) ) ; 
internal object[] m cols — new object[4]; 
internal int m fieldCount — 4; 


internal FsiDataReader() () 

internal FsiDataReader(string cmdText) () 

internal FsiDataReader(string cmdText, 
FsiConnection connection) ( 

m connection - connection; ) 

public object GetValue(int fieldIlndex) ( 

return m cols[(i); ) 


public Type GetFieldType(int fieldlndex) ( 
return m types(i)]; ) 


public string GetName(int fieldIndex) ( 
return m names[i); ) 


public int FieldCount ( 
get ( return m fieldCount; ) ) 


public int GetOrdinal(string fieldName) ( 
return Array. IndexOf(m names, name); ) 


public bool Read() ( 
if (m ie !-— null) ( 
if (m ie.MoveNext() -— true) ( 
m curRowtt; 
if (m fsilm curRow] is Filelnfo) ( 
Filelnfo f - (Filelnfo)m fsilm curRow] : 


m cols[0] - f.Name; 

m cols[1] - f.Length.ToString-( ) ; 

m cols[2] -— "Fájl"; 

m cols[3] - f.CreationTime.ToString(): ) 
else ( 


Directoryilnfo d - 
(DirectoryInfo)m fsilm curRow] ; 





m cols[0] - d.Name; 

m cols[1] — "0"; 

m cols[2] - "Mappa"; 

m cols[3] - d.CreationTime.ToString() ;)) 


return true; ) 
return false; ) ) 


internal void GetDirectory(string cmdText) ( 
m dir - new DirectoryInfo(cmdText) ; 

m fsi - m dir.GetFileSystemlnfos c ( ) ; 

m curRow — -1; 

m ie - m fsi.GetEnumerator(); ) 


Ezek után elkészíthetjük az IDbConnectionExtension inter- 
fészt implementáló FsiConnection osztályunkat is. 


public class 

FsiConnection: IDbDConnectionExtension( 

private string m connString; 

private ConnectionState m state — 
ConnectionState.Closed; 

private string m locName -— "File Share 
Information" ; 


public FsiConnection() () 
public FsiConnection(string connString) () 


public string ConnectionString ( 
get ( return m connString; ) 
set ( m connString -— value; ) ) 


public int ConnectionTimeout ( 
get ( return 0; ) ) 


public ConnectionState State ( 
get ( retum m state; ) ) 


public IDDTransaction BeginTransaction() ( 
throw new NotSupportedException(); ) 


public void Open( )( 
m state - ConnectionState.Open; ) 


public void Close() ( 
m state - ConnectionState.Closed; ) 


public IDbDCommand CreateCommand() ( 
return new FsiComnand(this); ) 
public string LocalizedName ( 

get ( return m locName; ) 

set ( m locName - value; ) ) ) 


Hasonlóképpen készül az /IDbCommand-ot megvalósító 
FsiCommand osztályunk is. Itt a CommandText tulajdon- 
ságban az SOL adatforrás esetén használt guerystring he- 
lyett a fájlmegosztás útvonala fog állni. 


public class FsiComnand : IDbCommand ( 
FsiConnection m connection; 
FsiTransaction m txn; 
string m cmdText; 
int m cmdTríimeout; 
FsiDataParameterCollection m parameters - 
new FsiDataParameterCollection() ; 


public FsiCommand() () 

public FsiCommand(FsiConnection connection) ( 

m connection - connection; ) 

public FsiCommand(string cmdText) ( 

m cmdText - cmdText; ) 

public FsiCommand(string cmdText, 
FsiConnection connection) ( 

m cmdText - cmdText; 

m connection - connection; ) 

public FsiCommand(string cmdText, 
FsiConnection connection, 
FsiTransaction txn) ( 

m cmdText - cmdText; 

m connection - connection; 

m txn — txn; ) 


public string CommandText ( 
get ( return m cmdTrext; ) 
set ( m cmdText — value; ) ) 


public int CommandTtimeout ( 
get ( return 30; ) 
set () ) 


public CommandType CommanaType ( 

get ( return CommandType . Text; 

set ( if (value !- CommandType.Text) 
throw new NotSupportedException(); ) ) 


public FsiDataParameterCollection Parameters ( 
get ( return m parameters; ) ) 


IDataParameterCollection IDbCommand.Parameters 


( 
get ( return m parameters; ) ) 


public IDbDTransaction Transaction ( 
get ( returm m txn; ) 
set ( m txn - (FsiTransaction) value; ) ) 


public IDataParameter CreateParameter() ( 
return (IDataParameter) 
(new FsiDataParameter()); ) 


public IDataReader ExecuteReader() ( 

if (m comnection —— null II] 

m connection.State !- ConnectionState . Open) 
throw new 

InvalidoperationException( "Nincs nyitott 

kapcsolat! "); 
FsiDataReader reader - new 
FsiDataReader(m cmdText) ; 

reader.GetDirectory(m cmdText) ; 
return reader; ) 


public IDataReader ExecuteReader 
(ComnandBehavior behavior) ( 


if (m connection -—— null II 
m connection.State !- ConnectionState . Open) 
throw new 


InvalidoperationException( "Nincs nyitott 
kapcsolat!"); 
FsiDataReader reader - new 
FsiDataReader(m cmdText) ; 
reader.GetDirectory(m cmdText) ; 
return reader; ) ) 


A fentiekhez hasonlóan rendre el kell készíteni az 
IDataParameter, . IDataParameterCollection . és  IDb 
Transaction interfészeket implementáló osztályokat is. Arra 
ügyeljünk, hogy egy egyedi elnevezésű, közös névtérhez 
tartozzon minden egyes osztály. Ha mindez megvan, szük- 
ségünk van egy projektreferenciára is: Microsoft. 
ReportingServices.Interfaces.díI (a Reporting Servicest 
ReportServerbin könyvtárában található). Az elkészült 
DLL-t be kell másolnunk a Weporting ServicesWteportSer- 
verbin és a MWicrosoft SOLServengoVtoolsWeportDe- 
signerbin könyvtárakba (privát szerelvény). Így mind a 
VS.NET Report Designer-ben, mind pedig a Report 
Manager-ben lehetőségünk lesz a meglévő négy (MSSOL, 
ORACLE, OLEDB, ODBC) kapcsolati típuson felül ezt az új 
,File Share Informatior" kapcsolatot is kiválasztani. Ahhoz, 
hogy ez megtörténjen, a következő bejegyzést kell adni a 
fenti két könyvtárban lévő RSReportServer.config és 
RSReportDesigner.config konfigurációs XML állományok 
Data eleméhez: 


cExtension Name-"FSI" 
Type-"NameSpace.FsiConnection, DLLName"/2 


A NameSpace helyett a közös névteret kell megadni, azaz 
az IDbConnection, lExtension interfészt tartalmazó osztály 
teljesen minősített nevét, a DLLName helyett pedig ér- 
telemszerűen a bemásolt DLL-ünk nevét, kiterjesztés nél- 
kül. Be kell még állítani a kódhozzáférési (Code Access 
Security - CAS) jogosultságot is a Weporting Servicesl 
ReportServervssrvpolicy.config . házirend (policy)  állo- 
mányban: 


cCodeGroup class-"UnionCodeGroup" 
version-"1" PermissionSetName-—"FullTrust" 
Name-"FSICodeGroup" Description-"Code group for 
my FSI data processing extension": 
cIMembershipCondition 
"UrlMembershipCondition" version—" 
C:NProgram FilesMicrosoft SAL 
Server MSSALNReporting 
ServicesNReportServerMbinDLLName.di11" /- 
£/CodeGroup? 









Valamint ugyanezt a Report Designer-hez is a Microsoft 
SOL ServensgoWoolsWteportDesignervspreviewpolicy.con- 
fig állományban: 


cxcCodeGroup class-"UnionCodeGroup" version—"1" 
PermissionSetName-"FullTrust" 


Name-"FSICodeGroup" 

Description-"Code group for my FSI data 

processing extension"? 

c ImembershipCondition 
class-"UrlMembershipCondition" version-"1" 
Ur1-"C:NProgram Filesicrosoft SOL 
ServerN8oNToolslRgeportbesignerbinNDLLName . d11" 

AS 

£/CodeGroup? 

Végül elindítjuk a VS.NET Report Designer-t (pl. varázslóval 
gyorsan összekattinthatunk egy 4 oszlopos mappainformá- 
ciós listát) vagy a Report Manager-t, úgy használhatjuk az 
adatforrásunk oszlopait, mintha az egy adatbázistábla 
négy különböző oszlopából olvasódna ki. Hasonlóképpen 
járhatunk el, ha a feladat például egy XML adatforrásra va- 


ló kiterjesztés. Bővebben itt: [5]. 
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Él http:[flocalhostfReportsjPagesfDataSource. aspx?ItemPath- xo2fSample-HReports Yo2fAdventuret 


SOL Server Reporting Services 
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Name: Adventureworks 
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ODBC 


File Share 





Connect Using: Informatior 


Kiterjesztett adatforrás a Report 
Manager-ben 


A kézbesítési helyek kiterjesztése 

Az eddig leírtakhoz hasonlóan implementálni kell az 
IDeliveryExtension, lExtension, ISubscriptionBase UlUser 
Control interfészeket (utóbbival saját kontrollokat is értel- 
mezhetünk az oldal és nyomtatótípus beállításához). Érde- 
mes megnézni a FPrinterDeliverySample példaalkalmazást, 
amelynek eredményeképpen nemcsak e-mail- és fájl- 
megosztás révén tudunk majd kimutatásokat kézbesíteni, 
hanem nyomtatóra is. 


A biztonság kiterjesztése 
Ha a beépített Windows- vagy Passport-hitelesítést űrlap 
alapúra szeretnénk felváltani, megvan rá a lehetőségünk. 
Akit érdekel a témakör, letölthetik a példaalkalmazást innen: 
[4], egy igen részletes és illusztrált leírás is tartozik hozzá, a 
lényege az eddig említett kiterjesztési technikához hasonlít. 
MÁTHÉ ZOLTÁN 
matbezabsi.bu 
MCSD. SOL Server MVP 
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A cikkben szereplő URL-ek: 
(1] http:/ / tinyurt.com /yvug3 

[2] http:/ / tinyuri.com/ 2dw93 

[3] http:/ / tinyuri.com/27c42 

[4] http:/ / tinyurt.com/ ?oubo 

(5] http:/ / tinyuri.com/yamph 
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EXCHANGE 2000/ EXCHANGE SERVER 2003 - III. RÉsZ 


Exchange témában egyelőre ez az utolsó cikk ebben 


a sorozatban. További apróságok mellett egy 








új kiegészítő komponenst és ennek a , kiegészítésnek 


a kiegészítését" 


Ni mire is jó az Exchange Server 2003-hoz kí- 
nált új kiegészítő komponens! 


Intelligent Message Filter 

A sokat sejtető nevű komponens egy újabb lehetőség a be- 
jövő levelek szűrésére. Ez a szűrő a spameket, azaz a le- 
vélszemetet szűri az alapján, hogy a levél a tartalma és for- 
mája mennyire ,spamgyanús". Az ,intelligencia" szó he- 
lyett én inkább a , titkos" szót tettem volna be a komponens 
nevébe, mert nagyon titkolózik a Microsoft, hogy pontosan 
miből is állapítja meg ezt a ,,pamgyanússágot". Valószínű, 
hogy elsődlegesen a nem korrektül meghatározott feladó- 
ból és a címzettek darapszámából. A végeredmény minde- 
nesetre az, hogy minden üzenet kap egy ún. SCL (spam 
confidence level) értéket, amely alapján tudunk szűrni. Az 
alábbi táblázatból kiderül, hogy ez az SCL paraméter mi- 
lyen értékeket vehet fel: 


SCL érték Spamkategória 


-1 Exchange szervezeten belüli levelek 
o Nem spam 
1tog 1: picit spamgyanús levél 


9: nagyon spamgyanús levél 


Tehát ezen SCL-paraméter alapján történik a levelek szűré- 
se, méghozzá két szinten. Az első szint maga az internetes 
bejárat SMTP virtuális szervere, azaz már az Exchange 
szervezet határán el tudjuk dobni egy bizonyos SCL-szintet 
elérő kéretlen leveleket. Ennek az a veszélye, hogy esetleg 
olyan levelek is áldozatul esnek, amelyek igazából szá- 
munkra nem spamek, csak úgy néznek ki. Ezért van a másik 
lehetőség, amelynél a levél eljut a klienshez, és ott kerül be 
a ,Junk E-mail" mappába, ha az SCL-érték az általunk beál- 
lított küszöbérték felett van. Itt már a felhasználó definiálhat 
egy olyan szabályt, hogy egy bizonyos feladó mégiscsak 
,Safe sender", így az ilyen levél a normál Inboxba kerül. A 
teljes folyamat, illetve az egyes szűrők egymáshoz viszonyí- 
tott helyzetét az 1. ábra mutatja. Természetesen, ha nincs 
külön Gateway funkciót ellátó Exchange kiszolgálónk, akkor 
a két szint feladatát egy Exchange is el tudja látni. 





ismertetjük. 
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1. ábra A szűrési folyamat és a szűrők 
helyzete 


Ha telepítettük az IMF komponenst, akkor a Global 
Settings/Message Delivery tulajdonságlapján tudjuk ezt a 
kétszintű szűrést hangolni: 


IEZEEZETTENEETTZZTT TT SNEK KKN 21 3e] 
General]  Defaults  ] — Sender Fitering KNszEet Fittering 1 
Recipient Filtering — ] — Detais inteligent Message Fiteing 





Configure spam confidence level (SCL) thresholds. Selecting a lower 
TönberTörtSESGÚTAKJBISGSK jöretsesebes Hat zoutl ég üneckeksd 
commercial e-mai (UCE). but it also incresses the likelihood of false 





posítives. 
f Gateway Blocking Configuration: 
Set the threshold for blocking UCE on gateway servers. 
Block messages with an SCL rating greater than or s 
egual to: [e Bi 
"when blocking messages: No Action r] 
r Store Junk E-mail Configuration 
Setthe threshold for moving UCE to a users Junk E-mail folder. 
Move messages with an SCL rating greater than or 
egual to: s zi 
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A Gateway résznél a következő eseményeket kérhetjük: 





No Action Csak annyit csinál, hogy beállítja az üzenetek 
SCL-attribútumát. 

Archive Berakja a beállított SCL-szint feletti üzenetet az 
ExchsrvrX Mailrootuwvsi nd UCEArchive könyvtárba. 
Ha mégis kézbesíteni kellene ezeket a levelet, 
akkor egyszerűen pakoljuk át a pickup könyvtárba. 








Delete Egyszerűen elfogadás után törli az üzenetet. 
Reject Közli a küldő SMTP kiszolgálóval, hogy nem fogadhatja 
ezt a levelet. 





Természetesen az adott SMTP virtuális szerveren is enge- 
délyezni kell a szűrő alkalmazását, ami a többi szűrőhöz 
képest kicsit más helyre költözött, nem a VS tulajdonság- 
lapjáról lehet elérni, hanem az SMTP konténerben található 
új objektumból. 











I Default SMTP Vatual Server 
E. Si 
[ [ T 





A Store-ra, azaz a felhasználók Junk e-mail-mappájába ke- 
rülő üzenetekre vonatkozó SCL-szint természetesen kisebb 
vagy egyenlő, mint a Gateway-nél beállított, hiszen amit be 
sem engedünk, azzal nincs sok értelme Store szinten bár- 
mit is kezdeni. 


Hogyan láthatjuk az SCL-szintet? 

Az IMF-en az SCL szintek beállításához — miután nem ismer- 
jük az algoritmust, amellyel ezek meghatározódnak - jó len- 
ne legalább látni, hogy az egyes spam levelek milyen SCL- 
értéket kapnak. A szomorú helyzet az, hogy alaphelyzetben 
ezt nem láthatjuk. Ezért is említettem korábban, hogy az ,in- 
telligens" helyett inkább a ,titkos" jelzőt kellett volna a ter- 
mék nevében szerepeltetni. De szerencsére nem ilyen rossz 
a helyzet, mert némi buherával ez is megjeleníthető. Először 
is el kell készíteni egy SCL.CFG fájlt, ami egy speciális űr- 
lap-definíció, ami már tartalmazza ezt az új SCL-attribútu- 
mot, és hozzá kell adni az Outlookhoz mint egy egyedi űrlap 
a következők szerint [1]. Ezután már megjeleníthetővé válik 
az SCL-érték a különböző mappanézetekben. 

A következő ábrán az utolsó oszlopban meg is jelenítettem 
az SCL-értéket, ami például egy telnet ablakban előállított, 
az adatmezőjében hiányos fejléccel rendelkező levél ese- 
tén 6-osnak adódik. 


Show Fields 


Maximum number of lines in multi.ine mode: [2 s] 
Select available fields from: 


Shaw these fields in this order: 
rnportance 
Icon 
Flag Status 
attachment 
J From 
"Subject 
Received 
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Junk E-mail 
1 Di giFrom 


3 Date: Yesterday To: 





Természetesen az SCL-értékeket felhasználhatjuk Search 
Folderek szűrőfeltételeinél és Rules Wizard szabályoknál 
is. Ilyenkor a kritériumnál az Advanced fülön a keresett me- 
zőt az ,SCL Extension Form" pontnál találjuk meg: 





Search Folder Criterja. (x) 





! Messages More Choices Advanced / 
Find items that match these criteria: 












Define more criteria: 


Freguently-used fields 
Address fields 
DatejTime fields 
All Document fields 
77 AllMail fields 
All Post fields 
All Contact fields 
All Appointment fields 
All Task fields 
All Journal fields 
All Note fields 
User-defined fields ín Inbox 
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Forms... 


További apróságok: 

felhasználó tiltása konnektoron 
Bizonyos esetekben szükséges lehet konnektorok haszná- 
latának tiltása személyek vagy csoportok részére, például 
az internetes levelezést tilthatjuk le ilyen módon. Úgy tűnik, 
hogy erre van is felület az Exchange kiszolgálónkon: 


ESTNEETETENZZTETTS E NNNN ZTE 
Content Restrictions ]  Delivery Options] Advanced ] 0 Details 
General 
Address Space]  Connected Routing Groups Delivery Restrictions 

















By default, messages Írom everyone are: 
cz REEz5iZd C Rejected 


Accept messages from: 


. ol 
Add... I Remove I 


Reject messages from: 
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Sajnos az itt beállítható tiltásokat és engedélyeket az 
Exchange alaphelyzetben figyelmen kívül hagyja. Ahhoz, 
hogy ezek működésbe lépjenek, definiálni kell egy registry 
bejegyzést: 


HKLMVSystemtCurrentControlSettServicesXResveNPar 
meters 
CheckConnectorRestrictions (DWORD) -— 1 


A beállítás érvényre jutásához még az SMTP és a Microsoft 
Exchange Routing Engine szolgáltatást is újra kell indítani. 
Ha ezek után olyasvalaki szeretne levelet küldeni egy ilyen 
konnektoron keresztül, akinek ezt megtiltottuk, sajnos nem 
túl bőbeszédű NDR hibaüzenetet kap: 


Reporting-MTA: dns; smtp-out.igjb .hu 
Final-Recipient: rfc822;VegetariJanosgodakint.hu 
Action: failed 
Statusiu5:7.1 
X-Display-Name: "! VegetariJanosgodakint.hu" 
Érdemes erről a hibajelzésről tájékoztatni az érintett fel- 
használókat. 


MI: meghajtó visszavarázsolása 

Az Exchange 2003-ban megszűnt az Exchange 2000-nél 
megszokott M: meghajtó, ami az Exchange adatbázisok- 
nak adott egy fájlrendszerszerű nézetet. Ennek oka az volt, 
hogy nagyon sokszor előfordult, hogy figyelmetlen rend- 
szergazdák ráeresztették a víruskeresőt erre a meghajtóra, 
és az ott mindenféle galibát okozott. 

Bizonyos esetekben azonban jó szolgálatot tehet nekünk 
ez a meghajtó, ezért szükséges lehet a megjelenítése, amit 
szintén egy registry-beállítással tehetünk meg: 


HKLMVSYSTEMCurrentControlSetYServicesNEXIFSNPar 
meters 
DriveLetter (REG SZ) -— M 


Természetesen nem muszáj M-nek hívni ezt a meghajtót, 
lehet bármilyen, még nem foglalt betű is. 

A beállítás érvényre juttatásához — miután ez egy rendszer- 
szintű szolgáltatás — a gépet újra kell indítani. 


Sürgős helyreállítás nem a Recovery 
Storage Groupba 

Új lehetőség az Exchange 2003-nál, hogy fel lehet venni 
egy újfajta adatbáziscsoportot, az ún. Recovery Storage 
Groupot. Ehhez hozzá lehet rendelni üzenet adatbázisokat, 
és ekkor a helyreállítás mentésből nem az ,igazi" üzenet 
adatbázist írja felül, hanem erre az alternatív helyre történik 
a visszatöltés. Erről az alternatív helyről aztán az Exmerge 
segédprogram segítségével lehet például a véletlenül tö- 
rölt üzeneteket visszarakni a figyelmetlen tulajdonos leve- 
lesládájábpa. De mi van akkor, ha épp használjuk a 
Recovery Storage Groupot, de pont egy olyan adatbázist 
kellene helyreállítani az ,igazi" helyére, amit hozzárendel- 
tünk az RSG-hez? Egyik lehetőség, hogy töröljük ezt on- 
nan, de ha ezt nem akarjuk, mert még dolgunk van vele, 
akkor ki lehet kapcsolni az RSG-ba történő helyreállítást a 
következő registry-beállítással: 


HKLMVSystemtCurrentControlSettServicesMMSExchange 


ISNParametersSystemVv 
Recovery SG Override (DWORD) — 1 


Jelszó módosítása OWA-n keresztül 
A jelszó megváltoztatása az Outlook Web Access felületen 
keresztül nem túl egyszerű. Először is azért, mert alaphely- 
zetben az Exchange 2003-nál ez a lehetőség ki van kap- 
csolva, amit az alábbi registry-érték módosításával kell be- 
kapcsolni: 


HKEY LOCAL MACHINENSYSTEMíCurrentControlSett 
ServicesAMSExchangewWEB 
DisablePassword (DWORD) -— 0 


Ha ezt megtettük, akkor már megjelenik a jelszó megvál- 
toztatását lehetővé tevő gomb a Beállítások oldalon: 
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Azonban ekkor sem örülhetünk még, mert ez még nem 
elég, a gombra kattintva egy hibás weboldalat kapunk. 
Merthogy még tanúsítványt kell szerezni az OWA-t futtató 
virtuális webkiszolgálóra, hogy lehetővé váljon az Exchange 
virtuális könyvtárakon az SSL titkosított csatornán történő 
kommunikáció. Ezután a következőket kell még elvégezni: 


1. Ebben a virtuális webkiszolgálóban újabb virtuális 
könyvtárat kell felvenni IISADMPWD néven. 

2. Ezt a Windows!lSystem32Vnetsrvvisadmpwd könyvtár- 
hoz kell kötni. 

3. Ellenőrizzük, hogy a virtuális könyvtár hozzáférésénél 
be vannak-e állítva a Read és a Run Scripts (Such As 
ASP) jogok. 

4. Az újonnan felvett virtuális könyvtár tulajdonságlapján 
az Authentication and Access Control szekcióban el- 
lenőrizzük, hogy az Enable Anonymous Access enge- 
délyezve van-e. 

Innentől kezdve a ,Jelszó módosítása" gombra kattintva 

megjelenik ez az oldal: 


A ns - Authentication Manager - Microsoft ... (E (Ela 


Internet Service 
Manager 


for Internet Information Server ő 0 


Domain 
Account 
Í 


Old password ! 


New password l 





Confirra new password / 





] ( Cancel ] 





( ok 
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OVVA funkcionalitás beállítása 

A jelszó megváltoztatásának lehetőségén kívül az OWA fe- 
lület számos egyéb funkcióját tudjuk hangolni. Ezt két szin- 
ten is megtehetjük: az egyik a kiszolgáló szintje, ilyenkor a 
következő registry-kulcsot kell igényeink szerint beállítani: 


HKEY LOCAL MACHINEVSYSTEM(CurrentControlSettV 
ServicesNXMSExchangeWebVOwA 
DefaultMailboxFolderSet (DWORD) 


A másik szint a felhasználónkénti beállítás, amit viszont az 
ADSIEdit eszközzel végezhetünk a felhasználói objektum 
attribútumai között: 


[eze sát ág 2] 


Attibute Editor ] Security ] 


[7 Show mandatory attibutes 

[7 Show optional attributes 

TT Show only attributes that have values 
Attributes: 














a: 
Unicode String  cNot Seb 


Mei 


Öctet S. ting 


msExchLabeledUR! 





msExchMailboxG uid Not Seb 


Mindkét esetben a következő bináris helyi értékekkel tu- 
dunk különböző OWA-funkciókat ki-be kapcsolni: 

Minden funkció: -1 (FFFFFFFF) Az egyes bitek (jobbról bal- 
ra): levelezés, naptár, névjegyalbum, feladatok, napló, fel- 
jegyzések, nyilvános mappák, emlékeztetők, új levélről ér- 
tesítés, gazdag kliens, helyesírás-ellenőrző, S/MIME, kere- 
sőmappák, aláírás, szabályok, témák, levélszemét. A kere- 
sőmappák csak akkor látszanak az OWA felületen, ha ko- 
rábban definiáltunk ilyet az Outlookból, egyébként az alap- 
helyzet szerinti keresőmappák nem látszanak, és nem is le- 
het az OWA felületből ilyeneket csinálni. 


Egynapos előadások projekimenedzsereknek, IT-vezetőknek 
A Microsoft legújabb termékei, technológiái azok számára, akiknek nem feladata 

a mindennapos üzemeltetés, hanem rendszerbevezetés tervezésével, informatikai 
infrastruktúra-projektek vezetésével, informatikai beszerzések ajánlatkérésének 


összeállításával és elbírálásával foglalkoznak. 


Új hivatalos tanfolyamok! 


Microsoft Systems Management Server 2003, Sharepoint Portal Server 2003. 


Microsoft SA oktatási kuponok beválthatók 


Connection Filterhez saját Relay 
Block List készítése 

Új szűrési lehetőség az Exchange 2003-ban a Connection 
Filter, ami a kiszolgálónkra kapcsolódó SMTP hostok IP- 
címét nézi meg különböző , feketelistákon", és e szerint be- 
zárja a kapcsolatot, vagy engedi tovább a kommunikációt. 
(Igazából nem a kapcsolódás időpontjában bont, hanem a 
,rFept to:" SMTP-parancs kiadása után.) Számos ilyen pub- 
likus RBL lista létezik, amelyeket a Connection Filter tulaj- 
donságlapján fel tudunk venni, azonban teszteléshez nem 
árthat egy saját RBL listát készíteni. Ennek módja egysze- 
rű. A DNS kiszolgálónkba vegyünk fel egy új forward 
lookup zónát, mondjuk, rbl.sajat néven. E zónában semmi- 
lyen dinamikus frissítésre nincs szükségünk. Vegyünk fel 
egy üres Host rekordot, ami a DNS-szerverünk IP-címét tar- 
talmazza. A tesztelendő IP-címet pedig vegyük fel ebbe a 
zónába Host rekordként, úgy, hogy a Host neve legyen az 
IP-cím, de fordított oktet sorrendben. Azaz például egy 
192.168.103.181 című gépet úgy tudunk feketelistára ten- 
ni, hogy az rbl.sajat zónába felveszünk egy 
181.103.168.192 nevű hostot, szokásjog alapján 127.0.0.x 
címmel. Az x különböző dolgokat jelent, nincs teljes 
egyetértés a különböző feketelistákon. Például: 


3 Spam-orrás 
eletet Open relay 


Ezek után a Connection Filternél felvehetjük Block List Ser- 
vice-ként a mi rbl.sajat feketelistánkat. 
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A MICROSOFT ELSŐ ASP.NEI ALAPÚ 


ÜZLETI ALKALMAZÁSA 


Szeptermberben jelerik meg Magyarországorv a Micro- 


soft ügyfélkapcsolat-kezelési rendszere, a Microsoft 





Customer Helationship Management (CRIM] 1.2 lokalizált 


változata. Cikksorozatunk első része rövid áttekintést 


nyújt a rendszer szolgáltatásairól és az alkalmazott 


technológiákról. Leírásunk természetesen nem teljes- 


körű, néhány példán keresztül mutatjuk beaz általunk 


leginkább érdekesnek ítélt funkciókat. 


A Microsoft CRM a kis- és középvállalatok számára kifej- 
lesztett ügyfélkapcsolat-kezelési megoldás. Elsősorban az 
operatív, azaz kereskedelmi folyamatok automatizálására 
és az ügyfélszolgálati tevékenységek támogatására hasz- 
nálhatjuk, de működése és felépítése miatt — mint azt a ké- 
sőbbiekben ismertetjük — lehetőségeink ebben még ko- 
rántsem merülnek ki. 

A Microsoft CRM teljes mértékben .NET technológiára épü- 
lő rendszer, amely számos további Microsoft technológiát 
és szerveroldali alkalmazást (Active Directory, IIS, SOL, Ex- 
change) használ működése során. A CRM könnyen illeszt- 
hető más üzleti rendszerekhez (InfoPath, MapPoint) illetve 
bármilyen ERP rendszerhez a BizTalk szerveren keresztül. 
A program felhasználói felülete a Microsoft Project 
2002/2003 rendszerekben már sikerrel alkalmazott webes 
megjelenést követi. 

Jelenleg két verzió közül választhatunk: alap (Standard) és 
professzionális (Professional), ezen belül lehetőségünk van 
kereskedelmi (Sales), illetve ügyfélszolgálati (Customer 
Service) licenc vásárlására, melyek egyben a CRM két fő 
modulját is meghatározzák. A licencek közötti funkcionali- 
tásbeli különbségekre utalni fogunk cikkünkben a megfele- 
lő helyeken. 


Kereskedelem (Sales) modul 

Elsőként ismerkedjünk meg a kereskedelmi modul kínálta 
funkciókkal! Mint általában az ügyfélkapcsolatokkal foglal- 
kozó szoftverekben, a kereskedelmi folyamatokat a Megke- 
resés (Lead) — Lehetőség (Opportunity) — Ajánlat (Ouote) — 
Megrendelés (Order) - Számla (Invoice) ,állomások", il- 
letve a hozzájuk kapcsolt tevékenységek (Activity) határoz- 
zák meg. Az adott kereskedelmi folyamatokhoz pedig part- 
nereket (Account) és kapcsolattartókat (Contact) társít- 
hatunk. 


Anélkül, hogy a kereskedelmi modul minden lehetőségét 
feltérképeznénk, nézzünk inkább egy példát a rendszer 
használatára! Tételezzük fel, hogy egy kereskedelmi akció- 
ban néhány száz emailt küldünk termékeinkkel kapcsolat- 
ban olyan cégeknek, amelyek eddig még nem vásároltak 
tőlünk (most az egyszerűség kedvéért ezt ne spamnek, ha- 
nem direkt marketingnek nevezzük). A CRM nyelvére lefor- 
dítva ez egy megkeresés és egy ehhez kapcsolt tevékeny- 
ség lesz. Esetünkben ez egy CRM e-mail, ami természete- 
sen sablon alapján készülhet. Az emailhez elég megadnunk 
az üzenet szövegét, a többi adatot (címzett, megszólítás, 
aláírás, stb.) a CRM majd hozzáteszi. Amennyiben levelünk- 
re választ kapunk, az automatikusan visszatalál a CRM 
rendszeren belül az általunk rögzített megkereséshez. 
Tegyük fel, hogy akciónk sikeres volt, és a cég érdeklődik 
termékeink iránt. A megkeresésből egy mozdulattal lehető- 
séget készíthetünk, és felvehetjük az adott céget partne- 
reink (Account) közé (természetesen a megkeresést nem 
csak mi indíthatjuk, de érzékeltetni akartuk a megkeresés 
és a lehetőség közötti különbséget). Ha van kapcsolattartó 
(Contact), azt is felvesszük; ez egyébként automatikusan 
megtörténik a megkereséskor bevitt adatok alapján. 
Ezután a lehetőségből ajánlatot készíthetünk, majd az aján- 
latból megrendelés, végül pedig számla készül. 
Tevékenységeink mindig a megfelelő helyre kerülnek rögzí- 
tésre:, így például a megrendeléssel kapcsolatos levelek, 
telefonok stb., a megrendeléshez, a számlával kapcsolato- 
sak pedig a számlához. A megrendelést és számlát egy 
automatizált munkafolyamat (workflow) segítségével küld- 
hetjük át ERP rendszerünkbe. Az egész folyamatot nagy- 
részt automatizálhatjuk is, úgy, hogy a felhasználó számára 
előírjuk, hogy mikor milyen lépéseket kell elvégeznie. 

Az előbbi esetben például a beérkezett válaszokhoz köte- 
lező tevékenységet rendelhetünk, amelyeket mindenkép- 
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pen el kell végezni, mielőtt lezárhatnánk a folyamatot. 
Megadhatjuk például, hogy a termék kiszállítása előtt tele- 
fonon egyeztetni kell a vevővel. A rendszer addig nem fog- 
ja lezárni a megrendelést, míg ez meg nem történik. 
Hasznos lehet, hogy termékeinkhez, partnereinkhez, illetve 
a folyamat bármely pontjához kapcsolhatjuk versenytár- 
saink adatait is (csak a professzionális verzióban). Termé- 
szetesen rengeteg további automatizálásra van lehetősé- 
günk a workflow-k segítségével. Az eladási folyamat leg- 
fontosabb automatizmusait az alapváltozat már eleve tar- 
talmazza. 

A felhasználói felület webes, de a modul Microsoft Outlook- 
ba integrált felhasználói felülettel is rendelkezik (Sales for 
Outlook Client), amely amellett, hogy offline működést is le- 
hetővé tesz, már általában ismerős a felhasználók számá- 
ra, így a beépülő CRM modul használata könnyen megta- 
nulható és használható. 


Ügyfélszolgálat 

(Customer Service) modul 

Az ügyfélszolgálat modul a szerződések (Contracts) és 
esetek (Cases), illetve az azokhoz kapcsolódó tevékenysé- 
gek kezelésén alapul. 

Eset lehet bármilyen, partnereink által kezdeményezett, 
megoldandó feladat: a vállalatunkkal kapcsolatos egysze- 
rű kérdés (például milyen termékeink vannak) megválaszo- 
lásától a termékreklamációkon át a szervizügyintézésig. 

A szerződés: adott partnerünkkel kapcsolatban milyen 
eseteket és hogyan oldunk meg. Megadhatjuk mikor állunk 
az ügyfél rendelkezésére, illetve milyen módon (telefonon, 
helyszínen) és milyen díjszabással végezzük tevékenysé- 
geinket. Ha már van szerződésünk a partnerrel, az elvég- 
zett tevékenységeket automatikusan ki is számlázhatjuk, és 
a szerződésben rögzíthetjük, milyen rendszerességgel 
tesszük ezt. 
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Felhasználói felület —- ügyfélszolgálat 
modul 


A fenti ábrán az ügyfélszolgálati modulban az aktív, még 
meg nem oldott esetek listáját látjuk. A cikksorozat további 
részeiben részletesebben is fogunk ezzel foglalkozni, most 
,kedvcsinálóként" néhány hasznos funkció: a különféle 
eseteket például automatikusan a megfelelő felhasználó- 
hoz tudjuk irányítani, vagyis mindegy ki rögzítette az esetet, 
az fog foglalkozni vele, aki ért hozzá. Így egy csapásra 
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megoldhatjuk azt is, hogy a partnerek ügyes-bajos és sür- 
gős dolgai ne a két hónapig szabadságon lévő munkatárs 
asztalán landoljanak. További lehetőségünk arra, hogy ne 
tűnjenek el nyomtalanul partnereink kérései: ha meghatáro- 
zott időn belül nem kerül egy eset megoldásra, a rendszer 
automatikusan üzenetet küldhet egy ezért felelős felhasz- 
nálónak (menedzser). 


Technológia 

A Microsoft CRM ízig-vérig .NET technológiákra épül. A 
rendszer felhasználói felületei XML webszolgáltatásokon 
keresztül kommunikálnak a CRM adatbázisaival, az adatok 
szinte kizárólag XML-ben utaznak az alkalmazás különbö- 
ző komponensei között. A CRM fejlesztői több mint nyolc- 
száz .NET osztályban valósították meg a funkcionalitást, 
amelyek nagy része a külső fejlesztők számára is elérhető 
a CRM SDK-n keresztül. A CRM rendszer nemcsak ,lóg a 
levegőben", hanem igen sok létező Microsoft technológiát 
integrál. A továbbiakban ezek közül a legfontosabbakkal 
való együttműködést tekintjük át. Némelyikkel kicsit részle- 
tesebben is foglalkozunk majd a következő részben, ahol a 
CRM szerver és a Sales for Outlook ügyfélalkalmazás tele- 
pítését ismertetjük. 





Active Directory (AD) 

A Microsoft CRM a felhasználók jogosultságainak kiosztá- 
sára és ellenőrzésére kizárólag az AD szolgáltatásait hasz- 
nálja, ezért a CRM felhasználók csak létező AD felhaszná- 
lók közül kerülhetnek ki. A CRM rendszer és az AD ilyen jel- 
legű szolgáltatásai között a kapcsolatot a CRM Security 
Service tartja. 

A rendszer működéséhez natív vagy W2K3 módban műkö- 
dő tartomány szükséges, amennyiben több erdőben egy 
CRM rendszert használunk, az erdők között kétirányú trust 
kapcsolatokat kell létrehoznunk. Telepítéskor meg kell ad- 
juk, hogy melyik szervezeti egységbe (OU) kerüljenek a 
CRM üzleti szervezeti egység (Business Unit) struktúrája 
alapján létrehozott további OU-k, melyekben a szerepkörök 
(Security Role) szerint a rendszer felhasználói csoportokat 
(NT Users Group) hoz létre. Ezekbe a csoportokba kerül- 
nek majd a felhasználók. 


Organizational FEGHEGÉK ő 


Unit 


BU1 BU2 


BU 4 


et 


BU5 


User € 


None 
CRM hozzáférési szintek 


Parent/Child BU 


Business Unit 
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Természetesen a jogosultságok kiosztását a CRM felhasz- 
nálói felületén végezhetjük el, ehhez nincs szükség az AD 
felügyeleti eszközeire, és különösebb AD ismeretekre sem. 
Vállalatunk szervezeti felépítésének alapegységei a CRM 
rendszerben az üzleti szervezeti egységek (Business Unit- 
ok). Ezekben helyezhetjük el a felhasználókat, illetve a sze- 
repköröket, amelyek a felhasználók hozzáférését határoz- 
zák meg az egyes CRM üzleti objektumokhoz. Ezeket az 
objektumokat rekordoknak nevezzük. CRM rekord például 
a partner, a megrendelés, a számla, a termék, a tevékeny- 
ség és a megjegyzés. A rekordok mezőkből állnak, mint 
például a név, termékkóada, ár. 

A hozzáféréseket az alábbi módon adhatjuk meg: 

mu meghatározzuk a szerepkörhöz kapcsolódó hozzáfé- 
rési szintet: user, business unit, parent-child business 
unit és organizational. 

m a jogosultságot rekordonként és műveletenként ad- 
hatjuk meg, azaz beállíthatjuk, hogy az adott rekordon 
milyen műveleteket lehet végezni. 

m a szerepkört felhasználóhoz rendeljük 


Példa: a felhasználóhoz rendelt szerepkör hozzáférési 
szintje business unit, a jogosultság a lehetőség rekordra ol- 
vasás szintű. Amennyiben a felhasználóhoz ezt a szerep- 
kört rendeljük, a business uniton belül minden lehetőség tí- 
pusú rekordra olvasás joga lesz. 





atais far azert] sas [ serve [doce Hiánagenert 


Record Type Create Rend Wíite Delete Aopend  AgpendTó Aga Shao 
Azon e e a e e 
antnet . e e e e 
Vesd e e e e e 
Ogportunty e e e e e 
heti e e 
te e e 
€-mag Temelate e 
eves Artie . 

Subject . 
aveve o e 
Mistellenevus brvndeges 
Pubint E-mad Terolatos 
fex 
10 ene seeded Vizet Brent 7 Prert: Chád Buzress Wnas 9 cranzaten 


ESETE EZT E EZ e Zs eze ez 


Szerepkörök beállítása a CRM-ben 





Nem véletlen, hogy a szerepköröket ilyen részletességgel 
határozhatjuk meg. A vállalatok életében döntő fontosságú, 
hogy a felhasználók hozzáférjenek a számukra fontos ada- 
tokhoz, azonban - különösen az utóbbi időkben - legalább 
ennyire hangsúlyos az üzleti adatok belső támadásokkal 
szembeni védelme. A CRM jogosultságkezelése erre igen 
kifinomult megoldást kínál. 


Crystal Reports 

A rendszerben rögzített adatokat természetesen használni 
is fogjuk valamire: segítségükkel elemezzük üzleti folyama- 
tainkat. Ehhez szükségünk van egy jelentéskészítő eszköz- 
re. A Microsoft itt lemondott a saját fejlesztésről, és partner- 
ként egy, ezen a területen igazi nagyágyút vont be: a 
Crystal Decisions-t. Maga a jelentéskészítő pedig a 
Crystal Enterprise for Microsoft CRM, azaz egy kifejezet- 
ten a Microsoft CRM rendszerhez készült eszköz, amely a 


CRM rendszerrel együtt automatikusan telepítésre kerül. 
Ennél a verziónál az adatforrás kizárólag az MSCRM lehet, 
illetve csak a CRM-en keresztül tekinthetők meg a jelenté- 
sek, módosításukra nincs lehetőségünk. 

Amennyiben a rendelkezésünkre álló, egyébként bőséges 
számú, összesen 119 jelentés nem elég, és újakat akarunk 
létrehozni vagy a meglévőket módosítani, szükségünk lesz 
a Crystal Reports 9 Professional, Developer, vagy Ad- 
vanced verziójára. Valószínűleg rossz vásárt nem csiná- 
lunk majd vele, mert a legtöbb ERP rendszerhez használ- 
hatjuk jelentéskészítő eszközként. 





TErystat ebe 


























Crystal Reports jelentés 


saLnL 

A CRM szerver a Microsoft SOL Server legalább Standard 
változatát igényli. Vigyázzunk, emiatt egy kisebb cégnél is 
a Small Business Server Premium verziójára van minimáli- 
san szükségünk, az MSDE (Desktop Engine) -— amit a Stan- 
dard verzióval kapunk - nem lesz elég (a teljes szöveges 
indexelés hiánya miatt már a telepítés sem lesz sikeres). A 
Sales for Outlook ügyfélalkalmazás egy külön MSDE pél- 
dányt igényel, ennek telepítését a telepítő elvégzi helyet- 
tünk. 

A CRM rendszer négy adatbázist hoz létre telepítésekor a 
következő neveken és tartalmakkal: CRM adatok: cOUs 4 
MSCRM, CRM rendszerleíró adatbázis: cOUs 4. Metaba- 
se, Crystal Reports adatok: cOUs 4 cServer names 4 
CRM Crystal, disztribúciós adatok a Sales for Outlook 
Client alkalmazáshoz: cOUs 4 MSCRMDIistribution. 

Az adatbázis sémáját közvetlenül soha ne módosítsuk. Ki- 
zárólag a rendszerleíró adatbázison keresztül tehetjük ezt 
úgy, hogy az adatbázis folyamatos működése és sértetlen- 
sége biztosítva legyen. 

Ha a CRM rekordokhoz új mezőket szeretnénk adni (pél- 
dául olyan egyéb adatokat is szeretnénk rögzíteni, ame- 
lyekre a meglévő mezők nem elegendőek), rendelkezé- 
sünkre áll egy felügyeleti eszköz, a Deployment Manager, 
melyben többek között erre is. lehetőségünk van. A terve- 
zésnél vegyük azonban figyelembe, hogy néhány rekord 
nem módosítható. A séma módosítását a cikksorozat kö- 
vetkező részeiben még tárgyalni fogjuk. 


Internet Information Services 

Mielőtt a CRM szervert telepítenénk, létre kell hoznunk egy 
virtuális könyvtárat, ahová a telepítés során a CRM ASPX 
lapjai kerülnek. Nem kell ezt megtennünk a Sales for 


Outlook Client telepítésekor (a telepítő ezt elvégzi helyet- 
tünk), bár ebben az esetben is szükséges lesz az IIS. 
A kliensgépre ugyanazok az ASPX lapok kerülnek, illetve 
azon ugyanazok a szolgáltatások működnek, mint a CRM 
szerveren. 

A szerver működéséhez minimálisan 5.5-ös verzió szüksé- 
ges (a Windows 2000 szerverben még ez található), de el- 
sősorban biztonsági okokból a 6.0-ás verzió javasolt; a Sa- 
les for Outlook Client telepítésekor is ez kerül a gépre. 
A kliensgépek esetében mindenképpen figyelembe kell 
vennünk, hogy telepítéskor egy teljes funkcionalitású web- 
kiszolgáló kerül a felhasználók gépére, így az ezzel kap- 
csolatosan felmerülő biztonsági kérdésekkel is foglalkoz- 
nunk kell. 


Exchange E-mail Router 

Ezt az összetevőt Exchange szerverünkre kell telepítenünk, 
melynek verziója 2000 vagy 2003 lehet. Az Exchange E- 
mail Router a CRM és az Exchange közötti kapcsolattartást 
végzi: kezeli a CRM rendszerből indított leveleinket, illetve 
a postaládánkba beérkező leveleket továbbítja a CRM felé. 
Lehetőségünk van csak az egyedi azonosítóval ellátott le- 
veleket beengedni, ebben az esetben a , levélválogatást" 
elvégzi a router. A CRM rendszerből indított, és valamilyen 


Főkuszban 


tevékenységünkkel, illetve bármely rekorddal (például egy 
lehetőséggel) összefüggő e-mail egyedi azonosítót, GUID- 
ot (Global Unigue Identifier) kap. Az azonosító az e-mail 
tárgy mezőjében kerül elhelyezésre, ez biztosítja hogy a 
válasz ,odataláljon" a megfelelő helyre, azaz ahhoz a re- 
kordhoz, amelyhez elküldött e-mailünk is tartozik. Ezt a 
feladatot is az Exchange E-mail Router szolgáltatás végzi. 
Természetesen ,beengedhetjük" a CRM rendszerbe ösz- 
szes levelünket is, és saját magunk kapcsolhatjuk őket a 
rekordokhoz, ez azonban nem javasolt: megfelelő jogosult- 
ságok birtokában akár magánlevelezésünkhöz is hozzáfér- 
hetnek más CRM felhasználók. 


Kovács LÁSZLÓ 

(MCSE-S, MCT, CRM vezető oktató) 
kovacslasbuilders.bu 

KovÁCs ZOLTÁN 

(MCSE. MCDBA, MCSD, MCT vezető fejlesztő) 
kovacszasbuilders.bu 

A szerzők a Számalk Oktatási Rt. 

Továbbképzés bivatalos Microsoft oktatói. 


a projektrmenedzsment 


Júniusban Budapesten volt a Nemzetközi Projektmenedzsment 
Szövetség 18. villágkongresszusa. A rendezvény támogatásában 
tevékenyen részt vállalt a Microsoft is, amely elkötelezett híve 

a projektmenedzsment fejlődésének. 


apjainkban a vállalatoknak, szervezeteknek fo- 

lyamatosan újabb, összetettebb és szorosabb 

együttműködést igénylő feladatokat kell megol- 
daniuk, éppen ezért fontos a különböző üzleti folyamatok, 
rendszerek, projektek áttekinthetővé tétele. A gyors és ha- 
tékony megoldásokat kínáló projektmenedzsmentet támo- 
gató eszközrendszerek egyre nagyobb szerepet kapnak a 
vállalatoknál. 
s Az információk összegyűjtése és elosztása jelentős időrá- 
fordítást kíván a projektvezetőktől. A Microsoft Windows 
SharePoint Services-zel integrált Nagyvállalati Projektme- 
nedzsment (Enterprise Project Management, EPM) megol- 
dása számos funkcióval támogatja a probléma megoldását. 
Segít például a projekttervek intranetes közzétételében, a 
projektmunkák engedélyeztetésében, projektmegbeszélé- 
sek szervezésében és megtartásában, jelentések generálá- 
sában, online kérdőívek készítésében és még rengeteg 
más hasznos funkcióval bővíti a napi munkát segítő lehető- 
ségeket" — mondta el az IPMA konferencián tartott előadá- 
sában dr. Shadt György, a Microsoft vezető tanácsadója. 
A Microsoft kiváló eszközöket kínál a projektek menedzse- 
lésére. Az Office Enterprise Project Management (EPM) le- 


hetővé teszi, hogy a szervezetek még hatékonyabban 
felügyelhessék és irányíthassák emberi erőforrásaikat, pro- 
jektjeiket és folyamataikat. A Microsoft Office EPM megol- 
dásával a teljes szervezet együtt dolgozhat a folyamatok 
állandó javítása érdekében, a hatékonyság növelhető, a tu- 
dás és az információk megosztása megkönnyíthető, és 
mindez a beruházás gyors megtérülését eredményezi. A 
jól ismert eszközök és a Microsoft Office Rendszer számos 
programjával való könnyű integrálódás révén az EPM 
megoldás elősegíti a vállalaton belüli széleskörű használa- 
tot, amivel pontosabban folyik a munka, jól láthatók a fele- 
lősök, és egyszerűbb a jóváhagyási folyamat is. 


kezdte e se 
www.microsoft.com/ hun, project 


EZT álat kása sásáae táj [s] 
idd lala ellalsia daai- ő 


http / wwwmicrosoft.com/ hun; office project, cdorderasp 
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Dr vV/Vatson 


BOLONDBIZTOS EFS 


Ebben a cikkberi nem az EFS (Encerypting File Systerr) mű- 


ködéséről, vagy használatáról olvashatnak, hanem 


arról, hogyari tehiető az E-S-reridszer bölöridbiztossá, 


hogyan növelhető a megbízhatósága a titkosított fájlok 


kibontásához szükséges magánkulcsok központi mentésé- 


vel. Kiválasztott vállalatunknál VVindows Server 2003-as 


tartormánykörnyezetet feltételezünk, amelyben egy Enter- 


prise (azaz Active Directoryval integrált) CA Server is van. 


a megkérdezzük a vállalatok rendszergazdáit, sze- 
rintük használja-e valaki náluk az EFS-t (titkosító 
fájlrendszer), a válaszolók 95 százaléka azt fogja 
mondani, hogy nem. Természetesen ez nem igaz. A Vezér- 
igazgató Elvtárs és sok más felhasználó, aki kényes adatok- 
kal dolgozik már régen megtanulta a szomszéd Pistikétől a 
titkosítás használatának fortélyait, és a legfontosabb fájljait 
titkosítva tárolja a merevlemezen, anélkül, hogy erről bárki- 
nek is szólt volna. Ami titok, az titok. Bezzeg felszínre kerül a 
titok, amint elvész a fájlok megnyitásához szükséges ma- 
gánkulcs! Ez pedig csupán idő kérdése, lévén hogy a fel- 
használó nemhogy azt nem tudja, hol van a létfontosságú 
magánkulcs, hanem azt sem, hogy ez a fogalom mit takar. 
Eljön a pillanat, amikor a Vezérigazgató Elvtárs betoppan az 
informatikushoz a laptopjával, és könyörögve kéri, hogy ál- 
lítsa vissza az eredeti állapotot. Ilyenkor fejveszett kapko- 
dás kezdődik, mert az informatikusnak sincs a leghalvá- 
nyabb elképzelése sem erről a titokzatos rendszerről (tisz- 
telet a kivételnek!). Némi olvasgatás után rájön, hogy a fáj- 
lok megnyitásához szükséges kulcsok a Vezér Elvtárs pro- 
filjában voltak, és máris összeáll a katasztrófa teljes képe: a 
kulcsok elvesztek, mivel: 
w valakik újratelepítették a Windowst vagy 
m letörölték a felhasználói profilt vagy 
m a Vezér maga törölte le a kulcspárt az Internet Explorer 
Tools " Internet Options menüjében matatva, vagy 
m megsérült a profilkönyvtár tartalma. 


Ez csak néhány gyakori eset, lehetséges azonban, hogy 
még ennél is kacifántosabb eljárás során veszett el a kulcs. 
Ez utóbbi akkor fordul elő, amikor a Vezér azt hiszi magáról, 
ért a számítástechnikához. Ilyenkor például kiexportálja az 
EFS tanúsítványt .CER fájlba (ebben nincs ám bent a privát 
kulcs!), és ezután, mint aki jól végezte dolgát, újrainstallálja 
a Windowst, majd az új oprendszerbe beimportálja az immár 
elárvult nyilvános kulcsot. Ahelyett hogy PFX-be exportált 
volna a bolond. Ésatöbbi, ésatöbbi, nem ragozom tovább. 

Egy szó mint száz, a magánkulcs végérvényesen elveszett. 





A fájlok megfejthetők lennének az úgynevezett Recovery 
Agent magánkulcsával - de az sincs meg. Illetve természe- 
tesen megvan, csak senki sem tudja, hogy hol. Vagy mégis- 
csak tudja valaki, hogy a legelőször telepített tartományve- 
zérlőn az Administrator profiljában van, de azt már nem sej- 
ti, hogyan lehetne összepároztatni az RA magánkulcsát a 
Vezér fájljaival. (Elárulom az egyik módszert: ki kell expor- 
tálni PFX-be, majd bejelentkezni Administratorként a lapto- 
pon, beimportálni a magánkulcsot is tároló PFX fájlt, és 
megnyitni a titkosított dokumentumokat.) 


Elveszett kulcs- visszavont kulcs? 
Foglalkozzunk még egy picit az elveszett EFS-kulccsal. 
Minden valamirevaló PKI-rendszerben alapkövetelmény, 
hogy ha egy magánkulcs kompromittálódik, a hozzá tartozó 
tanúsítványt vissza kell vonni. Ilyen eset lehet, ha a kulcs 
nyilvánosságra kerül, a kulcsot tároló Smart Card elvész 
stb. Ha ezeket az eseteket összevetjük az imént vázolt EFS- 
katasztrófával, lényeges különbséget vehetünk észre. Az 
EFS-magánkulcs általában egyszerűen megsemmisül, le- 
törlődik, tehát azzal senki visszaélni nem tud. Emiatt felesle- 
ges a visszavonásával bíbelődni, úgysincs belőle egyetlen 
példány sem. Sőt, talán érdemesebb volna az elveszett pél- 
dányt pótolni, hogy a felhasználó ott folytathassa titkosítási 
praktikáit, ahol abbahagyta. És itt jön be a képbe a Win- 
dows 2003 Certificate Services nagy újdonsága, a magán- 
kulcsok központi mentésének lehetősége! Ha megsemmi- 
sül egy kulcs, állítsuk vissza! 


Központi kulcsarchiválás, 
kulcsvisszaállítás 

Teljesen magától értetődik, hogy a központi kulcsarchiválást 
csak megfelelően biztonságos és megbízható környezetben, 
szigorú biztonsági házirend szabályok betartása esetén ér- 
demes használni. Ellenkező esetben a központi kulcstár át- 
megy központi kulcsgyárba, és pont a CA Serveren kerül nyil- 
vánosságra a felhasználók jelszóval védett, profilban tárolt 
magánkulcsa. 


Apropó profil. Mielőtt belemerülnénk a központi kulcsarchi- 
válás rejtelmeibe, érdemes megjegyezni, hogy csak azokat 
a magánkulcsokat lehet ilyen módon archiválni, amelyek 
egyébként is menthetők lennének, PFX-exportálás segítsé- 
gével. Tehát eleve kiesnek a körből a Smart Cardon gene- 
rált, illetve az exportálhatatlan típusú kulcspárok és tanúsít- 
ványok. Ennek oka abban keresendő, hogy központi archi- 
válás ide vagy oda, az RSA-kulcspárok az ügyfélnél gene- 
rálódnak, és onnan kerülnek archiválásra, ha ezt a kulcsok 
kezelése egyáltalán lehetővé teszi. 

Az EFS szinte kiált a központi kulcsarchiválásért, mivel eleve 
nem képes együttműködni Smart Carddal (csak tudnám, mi- 
ért?), és mint már említettem, a kulcs általában nem nyilvá- 
nosságra kerül, hanem elporlik a felhasználó keze között. 


Key Recovery Agent 

A központi kulcsarchiválás legeslegelső lépése, hogy kije- 
löljük azt a személyt vagy személyeket, akik katasztrófa 
esetén képesek lesznek a titkosítva tárolt magánkulcsot ki- 
nyerni a rendszerből, és odaadni a Vezérnek. Ők lesznek a 
Key Recovery Agentek (KRA), kulcsvisszaállító ügynökök. 
Amennyiben egynél több KRA-t jelölünk ki, számolnunk kell 
azzal, hogy egy KRA önmagában nem képes visszaállítani 
a mentett kulcsokat (lásd erről a TechNet tavalyi számait). 
Úgy válik egy normális Windows-felhasználó KRA-vá, hogy 
— stílszerűen - szert tesz egy KRA típusú X.509-es tanúsít- 
ványra. Ezt a tanúsítványtípust a CA Server alapfelállásban 
nem bocsátja ki, erre meg kell kérnünk őkelmét: 
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dort Authentsatan, Smart Card Logon l 
Key Recovery Agent tanúsítvány- 

típus engedélyezése a CA-n 


Ha valaki megnézné, kinek is van joga ilyen típusú tanúsít- 
ványt igényelni, azt tapasztalná, hogy a Domain Admins, 
Enterprise Admins csoport tagjai válhatnak KRA-vá. Ez nyil- 
ván túl népes társaság. Ha megkurtítjuk ezirányú jogaikat, 
visszaadják maguknak, hisz azért admin az admin, hogy 
azt is megtehesse, amit nem tehet meg! De nem kell ettől 
megijedni, mivel további védelmi vonal állja útját ezeknek a 
, gazfickóknak": a KRA-tanúsítványt a CA nem adja ki auto- 
matikusan, hanem egy CA Manager elfogadásától teszi 
függővé a kibocsátást. A CA Manager szerepet pedig telje- 
sen külön lehet választani a többi Windows-csoportól az 
úgynevezett Role Separation segítségével (ami egyébként 
Common Criteria-követelmény a CA-rendszerrel kapcsolat- 
ban). Amíg egy CA Manager el nem fogadja a tanúsítvány- 
kérést, addig az a Pending Reguests mappában szunnyad, 
és a KRA nem lép életbe. Most tételezzük fel, hogy a tanú- 
sítvány elfogadásra került. A következő lépés a CA Server 
felkészítése az archiválásra. 


A kulcsarchiválás bekapcsolása 

A CA Server tulajdonságlapján lehet beállítani, kik lesznek 
azok a KRA-k, akiknek a nyilvános kulcsával minden archi- 
vált magánkulcs titkosításra kerül. Érdemes megfontolni, 
hogy egynél több KRA-t jelöljünk ki, hisz a körúti butikot sem 
nyithatja ki egy lyány, meg kell várnia a kollegina megérke- 
zését. Egy CA-rendszer összes magánkulcsa pedig X 
nagyságrenddel értékesebb, mint az a néhány falatnyi női 
holmi, amihez egynél több , ügynök" jelenlétében lehet csak 
hozzáférni. Az én kis példámban csak egyetlen KRA lesz, 
de ez csak a demójelleg miatt van így! 
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General ] Policy Module ]  ExitModule ] Extensions ] Storage 
Certificate Managers Restrictions ] Auditing Recovery Agents ] Security 
Do the following when a certificate reguest includes key archival: 
€C Do not archive the key 
e Járchivethe key 

Number of recovery agents to use: 
n 


Key recovery agent certificates: 





Add... ] Remove ] View I 





KRA-k kijelölése a kulcsarchiválásra 


Itt értelemszerűen az Add... nyomógombbal lehet felvenni 
KRA-k tanúsítványát, míg a , Number of recovery agents to 
use:" az egyidejűleg szükséges butikoslányok száma. 

Az OK gomb megnyomása és a CA újraindulása után a CA 
Server kulcsarchiválásra kész. Nem így a tanúsítványok! Min- 
den egyes kulcsarchiválásra kijelölt tanúsítványsablonon be 
kell pipálni az archiválást engedélyezését: 


Ehet aldd 


Issuance Reguirements ] Superseded Templates ]/ Extensions ]/ Security ]/ 





General Reguest Handing SubjectName  ] 
Purpose: ! Encryption r] 





E SE san 


I Delete revoked or expired certíficates (do not archive) 


Magánkulcs archiválásának engedélyezése 
a tanúsítványsablonon 


És kész - lenne, ha a Basic EFS tanúsítványsablon ismerné 
ezt a lehetőséget. Mivel azonban az EFS egy , ősi" szolgál- 
tatás a sötét XX. századból, az ő sablonja feleannyi beállí- 
tást tartalmaz, mint szerencsésebb utódai. Nincs más hát- 
ra, alkotni kell egy új, Windows 2003-as verziójú EFS- 
tanúsítványsablont! 
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Ennek részleteivel nem fárasztanám a Tisztelt Olvasót. Akit 
komolyan érdekel a kulcsarchiválás és a PKI-rendszerek 
üzemeltetése, úgysem ússza meg a négynapos PKI 
Workshop tanfolyamot. Folytassuk tehát az elvekkel. 

Elvileg az új sablon elkészítésével feltettük az i-re a pontot. 
Ugyanakkor nem árt megjegyezni, hogy a munkaállomások 
csak akkor fárasztják magukat új EFS-tanúsítvány beszerzé- 
sével, ha még nincs nekik olyan. De pont a legturbóbb fel- 
használókra ez nem igaz, már rég van EFS-kulcspárjuk, hisz 
hónapok óta titkosítanak. A magánkulcs archiválását viszont 
csak egy új sablonnal készült új kulcspár teszi lehetővé. Ho- 
gyan cseréljük le egy távoli gépen az ott meglévő kulcspáro- 
kat és tanúsítványokat? Group Policyval! 


Tanúsítványok automatikus 
kibocsátása 

Szerencsére a Windows 2003 Group Policy már felhaszná- 
lók számára is lehetővé teszi az automatikus tanúsítvány- 
kiosztást. Ezt a lehetőséget fogjuk kiaknázni az új EFS- 
sablonunk terítésére. Az alábbi ábrát úgy próbáltam össze- 
hozni, hogy rajta legyen minden fontos jel ahhoz, hogy 
Önök is megtalálják a beállítást. Külön érdekessége az áb- 
rának, hogy pont akkor csapott bele az automatikus tanúsít- 
ványigénylés a Windowsba, amikor reszkető ujjamat a 
PrtScr gomb fölé vittem. Balra lent, a tálcán látszik a bubo- 
rékot dobó ikonocska, mely új tanúsítvány eljövetelére fi- 
gyelmeztet. (Teljesen suttyomban, a háttérben is működik, 
pusztán a látványosság kedvéért állítottam be úgy a házi- 
rendet, hogy kezdjen buborékozni, amint új tanúsítvány igé- 
nyelhető.) 
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Az automatikus tanúsítványigénylés GPO- 
beállítása 


Ha a felhasználó a buborékra kattint, megindul a kulcsgene- 
rálás, sőt, kulcsarchiválás folyamata. 


ETETETSTZTZTTTTT NNEEEN ESETET 3 
Vovagnntatot has serűsstgázos 
computer to automatically enroll new 

Bemind Me Later I 





certificates. 


To begin errolling certificates. click start. 
You may need to enter your password or 
PIN to access your private key. 





Automatikus tanúsítványkiosztás 






Egy nagyon fontos dologról ne feledkezzünk meg: az auto- 
matikus tanúsítványgeneráláshoz nem elegendő önmagá- 
ban a csoportházirend megfelelő beállítása. Jogosultság is 
kell hozzá. Minden egyes AutoEnroll-tanúsítványsablonon 
Read, Enroll és Autoenroll jogot kell adni a célszemélyeknek 
— a mi esetünkben egyszerűen az Authenticated Usersnek. 
Mostantól bárki bátran elhagyhatja EFS-kulcsait, lesz aki 
visszaadja neki: a KRA! De hogyan? 


Elveszett kulcsok visszaállítása 
2003-ban már megjelent egy cikk a TechNetben kulcs- 
visszaállításról Fülöp Miklós tollából. Ő a beépített parancs- 
sori lehetőséget taglalta. Én most inkább a sokkal könnyeb- 
ben használható grafikus felületet mutatom meg. A Win- 
dows 2003 Resource Kitben található a KRT.EXE (Key 
Recovery Tool) program, amivel (a KRA magánkulcsának 
birtokában!) játszva visszaállíthatjuk Vezér Elvtárs vagy 
Gipsz Jakab elveszett magánkulcsait. 

A sokféle tanúsítványkeresési módszer közül a domainy 
usert választottam, és megkerestem a saját archivált kul- 
csaimat: 


LL ASZNZa AKA 
Ele Help 


Certíkcation authorty (CA 


ALL CERTIFICATION AUTHORITIES - 


Select the seatch criteria, enter an appropriate value, and then cick 
"Search" to dsplay a kat ol malching archrved keys. 


Search Ciiteria 
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Value 


Inetacademiatmarcettt 


Í CenHashíshat) 
8215666e7012 


Certíicates 
Serial Number [ Subject 
3) Sdddd7a. . CNeMarcet Foti, OU. 





TTemelste 
BasicEFSwihkep. 


TNaBetoe  T Notátter 
478/2004 8/6/2004 





To recover a private key, select the associated certificate above and then cbck "Recover" 
ShowKRA. Retieve Blob... )  Deciypt Blob. Recgyer 
Help 





Statur [fosgy 


Archivált kulcspárok listája 


Ha egynél több KRA lett beállítva, most megtudhatjuk, hogy 
melyiküket kell berángatni szabadságról, ha a Snow KRA 
gombra kattintunk. Mint kiderült, az én másik felhasználói 
fiókom (fm) az a KRA, akire szükség lesz: 


Key Recovery Agents Used for Archival 











Serial Number Í Subject 
Eg] 5a1fa413000200000.... CNefm. OU-Mi DCsne. 


Í Cent Hashíshat) 
€2b1 93 a7 23 36 44 


Iesving CA 
CNeca netacademia n 





Itt olvasható, melyik KRA-ra van szükség a 


visszaállításhoz 


A Recover gombra kattintva pedig elkészíthetjük azt a PKCS 

12-es (.PFX) fájl, amivel a hiányzó kulcsok a felhasználó szá- 
mítógépén pótolhatók. 

Főti Marcell 

marcellfeonetacademia.net 

MCT, MCSE. MCDBA, MZ/X 
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Arccal az MCSA felé! 


Akciónk keretében a Microsoft Windows 2003 rendszeradminisztrátor minősítés 
(MCSA) megszerzéséhez szükséges 3 -- I tanfolyamot megrendelők részére cégünk 
a vizsgákat ingyenesen biztosítja. 


dik 
ks raésités elk j: k 
Az MCSA minősítés előnyei gy ze e a 


KI Az Ön szakmai felkészültségének elismerése az iparágon belül. 

I Közvetlen hozzáférés az MCP tagok weboldalán keresztül 
a Microsoft legírissebb technikai és termékinformációihoz. 

Ki Az adott minősítést igazoló logók elérhetősége és használata 
(szabályozott kereteken belül). 

Ki Ingyenes vagy kedvezményes meghívások itthoni és külföldi 
konferenciákra, tanulmányutakra, rendezvényekre. 

Ki Ingyenes hozzáférés a Microsoft MCP Online Magazine-ra és 
egyéb minősítés-specifikus számítástechnikai kiadványokhoz. 

IH A kedvezményes előfizetés a Windows 8 .NET Magazinokra. 

E Illetve néhány közvetett előny (például karrierlehetőségek itthon 
és külföldön). 






Az MCSA-képesítés a következő feladatok elvégzésére készít fel: 


Microsoft Windows Server 2003 környezetek menedzselése és hibaelhárítása. 
Active Directory kialakítása és üzemeltetése. 

Group Policy Objektumok létrehozása és konfigurálása. Felhasználói 
környezet kezelése csoportos házirenddel. 

Erőforrások hozzáférésének kezelése. 

A kiszolgáló teljesítményének monitorozása. 

Katasztrófa előtti állapot visszaállításának kezelése (Disaster Recovery). 
Szoftverek karbantartása Software Update Services használatával. 
TCP/IP alapú hálózati környezetek kialakítása. 

Biztonságos hálózat kialakítása. 

Munkaállomások telepítése és konfigurálása. 

Az új ISA Server 2004 konfigurálása és üzemeltetése. 


A részvétel feltételei: 


I A résztvevőknek egy éven belül el kell végezniük mind a négy MCSA tanfolyamot. 

IH Az ingyenes vizsgabónt mindig a következő tanfolyam megrendelésekor adjuk ki (tehát 
az elsőt a második tanfolyam megrendelése után, a 2. bónt a 3. tanfolyam után stb.). 

KH Jelentkezési határidő: 2004. szeptember 15. 


Az összeállítás csak egy a lehetőségek közül. 





A teljes kínálatról tájékozódjon honlapunkon! 
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